Importing module?

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

Re: Importing module?

Yitzak wrote:
> 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

Re: Importing module?

"Yitzak" 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

Re: Importing module?

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" 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

Re: Importing module?

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" wrote in message
news:4bc1cbff-d8c6-45e6-aac9-9e5933a76814@z17g2000hsg.google groups.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" 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

Re: Importing module?

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:
> 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" wrote in message
> news:4bc1cbff-d8c6-45e6-aac9-9e5933a76814@z17g2000hsg.google groups.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" 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