Import Form

Import Form

Hello,

Using Access ’03…

I’m wondering if I can do the following:

I have two database files (A.mdb and B.mdb). Can I write code in
A.mdb that when opened (say in an auto exec macro) looks in B.mdb and
imports a specific form (the same form every time--replacing it)?

I know I can export a form (not sure how to do it with VBA) but I
really need the code to import the form because I’ll be placing it in
several mdb files that will be in various places on the network.

Thanks for the help,
alex

On Thu, 4 Mar 2010 16:10:51 -0800 (PST), alex wrote:

Import Form

Hello,

Using Access ’03…

I’m wondering if I can do the following:

I have two database files (A.mdb and B.mdb). Can I write code in
A.mdb that when opened (say in an auto exec macro) looks in B.mdb and
imports a specific form (the same form every time--replacing it)?

I know I can export a form (not sure how to do it with VBA) but I
really need the code to import the form because I’ll be placing it in
several mdb files that will be in various places on the network.

Thanks for the help,
alex

Take a look at the VBA help for "TransferDatabase". This is the code version
of File... Get External Data... Import and/or File... Export.

However, I cannot IMAGINE why you would want to bloat your database by
repeatedly importing the same form!!!! What is changing about the form that
you need to keep importing a new one?

--

John W. Vinson [MVP]

On Mar 4, 8:45*pm, John W. Vinson
wrote:
On Thu, 4 Mar 2010 16:10:51 -0800 (PST), alex wrote:
Import Form

Hello,

Using Access ’03…

I’m wondering if I can do the following:

I have two database files (A.mdb and B.mdb). *Can I write code in
A.mdb that when opened (say in an auto exec macro) looks in B.mdb and
imports a specific form (the same form every time--replacing it)?

I know I can export a form (not sure how to do it with VBA) but I
really need the code to import the form because I’ll be placing it in
several mdb files that will be in various places on the network.

Thanks for the help,
alex

Take a look at the VBA help for "TransferDatabase". This is the code version
of File... Get External Data... Import and/or File... Export.

However, I cannot IMAGINE why you would want to bloat your database by
repeatedly importing the same form!!!! What is changing about the form that
you need to keep importing a new one?

--

* * * * * * *John W. Vinson [MVP]- Hide quoted text -

- Show quoted text -

Hi John; thanks for helping.
I'm making continuous modifications to this form (mostly adding
functionality). It's a form that builds queries for linked sql server
tables. I add different queries about once a week (at least for
now...less as time goes on). Should I be doing something different?
alex

On Fri, 5 Mar 2010 04:22:11 -0800 (PST), alex wrote:


Hi John; thanks for helping.
I'm making continuous modifications to this form (mostly adding
functionality). It's a form that builds queries for linked sql server
tables. I add different queries about once a week (at least for
now...less as time goes on). Should I be doing something different?
alex

If you use proper Parameter queries, then there should only rarely be a need
to create a new query or a new form. I don't know your database structure
though so you may be doing fine.

I'd be inclined to use a split database (tables in a shared backend, probably
SQL/Server) and all the forms, queries, etc. in a personal frontend. When you
come up with a new feature, don't import the form - just *delete the entire
database* and replace it with the new model. There are several tools available
to make this process easier; Tony Toews' Auto Frontend Updater at
http://autofeupdater.com/ is very through and effective.
--

John W. Vinson [MVP]

On Mar 5, 12:36*pm, John W. Vinson
wrote:
On Fri, 5 Mar 2010 04:22:11 -0800 (PST), alex wrote:
Hi John; thanks for helping.
I'm making continuous modifications to this form (mostly adding
functionality). *It's a form that builds queries for linked sql server
tables. *I add different queries about once a week (at least for
now...less as time goes on). *Should I be doing something different?
alex

If you use proper Parameter queries, then there should only rarely be a need
to create a new query or a new form. I don't know your database structure
though so you may be doing fine.

I'd be inclined to use a split database (tables in a shared backend, probably
SQL/Server) and all the forms, queries, etc. in a personal frontend. When you
come up with a new feature, don't import the form - just *delete the entire
database* and replace it with the new model. There are several tools available
to make this process easier; Tony Toews' Auto Frontend Updater athttp://autofeupdater.com/is very through and effective.
--

* * * * * * *John W. Vinson [MVP]

That makes sense John...
Also, regarding the bloating you mentioned (which I completely
understand); If I (or my users) compact the db after a new form is
imported (replacing the previous one), the size will stay consistent
(barring any other changes)--correct?
alex

On Fri, 5 Mar 2010 10:12:34 -0800 (PST), alex wrote:

Also, regarding the bloating you mentioned (which I completely
understand); If I (or my users) compact the db after a new form is
imported (replacing the previous one), the size will stay consistent
(barring any other changes)--correct?

More or less. Compaction isn't perfect; the size can creep up, and there's
always at least some risk of corruption. Since there is (I presume) no actual
data and no user-specific information stored in the frontend, it's easier just
to toss and replace.

Of course if your users have design rights and make their own forms or
queries, it's a different story!
--

John W. Vinson [MVP]

On Mar 5, 1:47*pm, John W. Vinson
wrote:
On Fri, 5 Mar 2010 10:12:34 -0800 (PST), alex wrote:
Also, regarding the bloating you mentioned (which I completely
understand); If I (or my users) compact the db after a new form is
imported (replacing the previous one), the size will stay consistent
(barring any other changes)--correct?

More or less. Compaction isn't perfect; the size can creep up, and there's
always at least some risk of corruption. Since there is (I presume) no actual
data and no user-specific information stored in the frontend, it's easier just
to toss and replace.

Of course if your users have design rights and make their own forms or
queries, it's a different story!
--

* * * * * * *John W. Vinson [MVP]

Got it. Thanks John!
alex

"alex" wrote in message
...
On Mar 5, 12:36 pm, John W. Vinson
wrote:
On Fri, 5 Mar 2010 04:22:11 -0800 (PST), alex wrote:
Hi John; thanks for helping.
I'm making continuous modifications to this form (mostly adding
functionality). It's a form that builds queries for linked sql server
tables. I add different queries about once a week (at least for
now...less as time goes on). Should I be doing something different?
alex

If you use proper Parameter queries, then there should only rarely be a
need
to create a new query or a new form. I don't know your database structure
though so you may be doing fine.

I'd be inclined to use a split database (tables in a shared backend,
probably
SQL/Server) and all the forms, queries, etc. in a personal frontend. When
you
come up with a new feature, don't import the form - just *delete the
entire
database* and replace it with the new model. There are several tools
available
to make this process easier; Tony Toews' Auto Frontend Updater
athttp://autofeupdater.com/is very through and effective.
--

John W. Vinson [MVP]

That makes sense John...
Also, regarding the bloating you mentioned (which I completely
understand); If I (or my users) compact the db after a new form is
imported (replacing the previous one), the size will stay consistent
(barring any other changes)--correct?
alex

"alex" wrote in message
...
On Mar 4, 8:45 pm, John W. Vinson
wrote:
On Thu, 4 Mar 2010 16:10:51 -0800 (PST), alex wrote:
Import Form

Hello,

Using Access ’03…

I’m wondering if I can do the following:

I have two database files (A.mdb and B.mdb). Can I write code in
A.mdb that when opened (say in an auto exec macro) looks in B.mdb and
imports a specific form (the same form every time--replacing it)?

I know I can export a form (not sure how to do it with VBA) but I
really need the code to import the form because I’ll be placing it in
several mdb files that will be in various places on the network.

Thanks for the help,
alex

Take a look at the VBA help for "TransferDatabase". This is the code
version
of File... Get External Data... Import and/or File... Export.

However, I cannot IMAGINE why you would want to bloat your database by
repeatedly importing the same form!!!! What is changing about the form
that
you need to keep importing a new one?

--

John W. Vinson [MVP]- Hide quoted text -

- Show quoted text -

Hi John; thanks for helping.
I'm making continuous modifications to this form (mostly adding
functionality). It's a form that builds queries for linked sql server
tables. I add different queries about once a week (at least for
now...less as time goes on). Should I be doing something different?
alex

,n;;,v;,v

"John W. Vinson" a écrit dans le
message de groupe de discussion :
...
On Fri, 5 Mar 2010 10:12:34 -0800 (PST), alex wrote:

Also, regarding the bloating you mentioned (which I completely
understand); If I (or my users) compact the db after a new form is
imported (replacing the previous one), the size will stay consistent
(barring any other changes)--correct?

More or less. Compaction isn't perfect; the size can creep up, and there's
always at least some risk of corruption. Since there is (I presume) no
actual
data and no user-specific information stored in the frontend, it's easier
just
to toss and replace.

Of course if your users have design rights and make their own forms or
queries, it's a different story!
--

John W. Vinson [MVP]