dbTalk Databases Forums  

Importing module?

comp.databases.ms-access comp.databases.ms-access


Discuss Importing module? in the comp.databases.ms-access forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Yitzak
 
Posts: n/a

Default Importing module? - 01-21-2008 , 08:05 AM






Hi

I've got a mdb that is recreated monthly/weekly.

I've written a bas module with lots of functions in it so that they
can be used in queries.

What is an easy way to import the bas module into the newly created
mdb. I've exported it as a text file.

There does not seem to be a method of importing the file. The only way
is to insert a new module then insert file and selected the file I
previously exported.

Thanks

Reply With Quote
  #2  
Old   
Salad
 
Posts: n/a

Default Re: Importing module? - 01-21-2008 , 09:53 AM






Yitzak wrote:
Quote:
Hi

I've got a mdb that is recreated monthly/weekly.

I've written a bas module with lots of functions in it so that they
can be used in queries.

What is an easy way to import the bas module into the newly created
mdb. I've exported it as a text file.

There does not seem to be a method of importing the file. The only way
is to insert a new module then insert file and selected the file I
previously exported.

Thanks
File/GetExternalData/Import (select mdb to import from), click Import,
then select the module and press OK.

JPGR
http://www.youtube.com/watch?v=QvlVBopw-co


Reply With Quote
  #3  
Old   
Larry Linson
 
Posts: n/a

Default Re: Importing module? - 01-21-2008 , 05:49 PM



"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote

Quote:
I've got a mdb that is recreated monthly/weekly.
If you'd explain what you have, what you are trying to accomplish, and why
you felt it necessary to re-create weekly and/or monthly a database into
which you have to copy a module, perhaps someone can offer you useful
suggestions. My comment would be, perhaps you have an exception, but there
is almost never a compelling reason to re-create a similar database on a
periodic basis.

Quote:
I've written a bas module with lots of functions
in it so that they can be used in queries.

What is an easy way to import the bas module
into the newly created mdb. I've exported it as
a text file.
If there is some compelling reason why you can't use Salad's suggestion of
importing the module directly from the database where it resides, then you
can open a new module in the new database, highlight, copy, and paste the
module code.

Larry Linson
Microsoft Access MVP




Reply With Quote
  #4  
Old   
Yitzak
 
Posts: n/a

Default Re: Importing module? - 01-23-2008 , 10:54 AM



Thanks Salad. That did the trick.

Larry the DB is re-created with new products from an external source.
To be honest I really don't wanna get into this area - can of worms,
probably doesn't need to.

Out of interest how does one share vba code around, i.e. say I have a
couple of BAS modules with lots of useful routines. Linking seems to
work only with tables? Import just SEEMS to copy the bas module over

What I'm trying to achieve here is in case of code fix, I don't have
to change every DB that references it. But change the one that all
others "link to".

Short of compiling it into a VB dll and referencing it in Access,
which still wouldn't be ideal, but would probably still need a bas
module as a wrapper to instaniate and wrapp teh calls to the dll.


Larry Linson wrote:
Quote:
"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote

I've got a mdb that is recreated monthly/weekly.

If you'd explain what you have, what you are trying to accomplish, and why
you felt it necessary to re-create weekly and/or monthly a database into
which you have to copy a module, perhaps someone can offer you useful
suggestions. My comment would be, perhaps you have an exception, but there
is almost never a compelling reason to re-create a similar database on a
periodic basis.

I've written a bas module with lots of functions
in it so that they can be used in queries.

What is an easy way to import the bas module
into the newly created mdb. I've exported it as
a text file.

If there is some compelling reason why you can't use Salad's suggestion of
importing the module directly from the database where it resides, then you
can open a new module in the new database, highlight, copy, and paste the
module code.

Larry Linson
Microsoft Access MVP

Reply With Quote
  #5  
Old   
Larry Linson
 
Posts: n/a

Default Re: Importing module? - 01-23-2008 , 08:29 PM



Yitzak,

I was hoping you'd explain why you have data tables and modules in the same
database.

If you separate the datatables and relationships ("back end") from the
queries, forms, reports, macros, and modules ("front end"), and link the
backend tables from the front end, you will not have to recreate the front
end unless the _structure/design_ of the back end changes. It sounds to me
that you have data that is changing but you haven't followed the good design
practice of splitting the database.

Code that you wish to share can be put into a separate database, and you
include a Reference to that database in Tools | References in the Module
Window. You'll find more on that subject in the archives of this newsgroup
at http://groups.google.com, in one of several sites for which I have links
at http://mail.ntpcug.org/accesssig/default.aspx, or at one of these
microsoft websites: http://support.microsoft.com (home of the Microsoft
Knowledge Base) or http://msdn.microsoft.com (searchable for many useful
articles). In the days of Access 1.0, 1.1, and 2.0, those were typically
named .MDA files; since then, they have been "compiled" (for easier loading
and use of the content) and called .MDE files.

One primary reason for splitting is that you don't have to worry about
front-end objects, just because you get some changed data... Splitting is so
particularly helpful in the multiuser environment that some may forget that
it is proper practice for production applications, even if they are
single-user.

Larry Linson
Microsoft Access MVP



"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote

Quote:
Thanks Salad. That did the trick.

Larry the DB is re-created with new products from an external source.
To be honest I really don't wanna get into this area - can of worms,
probably doesn't need to.

Out of interest how does one share vba code around, i.e. say I have a
couple of BAS modules with lots of useful routines. Linking seems to
work only with tables? Import just SEEMS to copy the bas module over

What I'm trying to achieve here is in case of code fix, I don't have
to change every DB that references it. But change the one that all
others "link to".

Short of compiling it into a VB dll and referencing it in Access,
which still wouldn't be ideal, but would probably still need a bas
module as a wrapper to instaniate and wrapp teh calls to the dll.


Larry Linson wrote:
"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote

I've got a mdb that is recreated monthly/weekly.

If you'd explain what you have, what you are trying to accomplish, and
why
you felt it necessary to re-create weekly and/or monthly a database into
which you have to copy a module, perhaps someone can offer you useful
suggestions. My comment would be, perhaps you have an exception, but
there
is almost never a compelling reason to re-create a similar database on a
periodic basis.

I've written a bas module with lots of functions
in it so that they can be used in queries.

What is an easy way to import the bas module
into the newly created mdb. I've exported it as
a text file.

If there is some compelling reason why you can't use Salad's suggestion
of
importing the module directly from the database where it resides, then
you
can open a new module in the new database, highlight, copy, and paste the
module code.

Larry Linson
Microsoft Access MVP



Reply With Quote
  #6  
Old   
Yitzak
 
Posts: n/a

Default Re: Importing module? - 01-24-2008 , 01:07 PM



Thanks Larry

The db I've just become aware of, its produced from an external
company has no front-end. It is used to match to another AccessDB
(which in turn points to a MSSQL DB). I ported the other to MSSQL but
kept links via ODBC becuase the user/owner is familiar with Access
queries and frankly nothing I could ever write would be as good as
Access. Its excellent at this.

However I've just thought if the DB is recreated everytime, where does
he get the queries. I think what happens is data is wiped and
reimported monthly.

These were the first modules I wrote in Access and the simple
functions are to be used in string formatting/splitting in queries no
forms, reports etc etc.

I added the module to the DB becuase didn't realize you could link via
tools|refs.

Yitzak..





Larry Linson wrote:
Quote:
Yitzak,

I was hoping you'd explain why you have data tables and modules in the same
database.

If you separate the datatables and relationships ("back end") from the
queries, forms, reports, macros, and modules ("front end"), and link the
backend tables from the front end, you will not have to recreate the front
end unless the _structure/design_ of the back end changes. It sounds to me
that you have data that is changing but you haven't followed the good design
practice of splitting the database.

Code that you wish to share can be put into a separate database, and you
include a Reference to that database in Tools | References in the Module
Window. You'll find more on that subject in the archives of this newsgroup
at http://groups.google.com, in one of several sites for which I have links
at http://mail.ntpcug.org/accesssig/default.aspx, or at one of these
microsoft websites: http://support.microsoft.com (home of the Microsoft
Knowledge Base) or http://msdn.microsoft.com (searchable for many useful
articles). In the days of Access 1.0, 1.1, and 2.0, those were typically
named .MDA files; since then, they have been "compiled" (for easier loading
and use of the content) and called .MDE files.

One primary reason for splitting is that you don't have to worry about
front-end objects, just because you get some changed data... Splitting is so
particularly helpful in the multiuser environment that some may forget that
it is proper practice for production applications, even if they are
single-user.

Larry Linson
Microsoft Access MVP



"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote in message
news:4bc1cbff-d8c6-45e6-aac9-9e5933a76814 (AT) z17g2000hsg (DOT) googlegroups.com...
Thanks Salad. That did the trick.

Larry the DB is re-created with new products from an external source.
To be honest I really don't wanna get into this area - can of worms,
probably doesn't need to.

Out of interest how does one share vba code around, i.e. say I have a
couple of BAS modules with lots of useful routines. Linking seems to
work only with tables? Import just SEEMS to copy the bas module over

What I'm trying to achieve here is in case of code fix, I don't have
to change every DB that references it. But change the one that all
others "link to".

Short of compiling it into a VB dll and referencing it in Access,
which still wouldn't be ideal, but would probably still need a bas
module as a wrapper to instaniate and wrapp teh calls to the dll.


Larry Linson wrote:
"Yitzak" <terryshamir (AT) yahoo (DOT) co.uk> wrote

I've got a mdb that is recreated monthly/weekly.

If you'd explain what you have, what you are trying to accomplish, and
why
you felt it necessary to re-create weekly and/or monthly a database into
which you have to copy a module, perhaps someone can offer you useful
suggestions. My comment would be, perhaps you have an exception, but
there
is almost never a compelling reason to re-create a similar database on a
periodic basis.

I've written a bas module with lots of functions
in it so that they can be used in queries.

What is an easy way to import the bas module
into the newly created mdb. I've exported it as
a text file.

If there is some compelling reason why you can't use Salad's suggestion
of
importing the module directly from the database where it resides, then
you
can open a new module in the new database, highlight, copy, and paste the
module code.

Larry Linson
Microsoft Access MVP

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.