best practices to share code in multiple databases

[Sue L.]

Hi,

I would like to share code with several databases and be able to update the
code in one place and have all of the databases be using the updated code.

Besides code, I would like to do the same with forms.

Can I customize a textbox and then put the custom textbox on a form?

Thanks,

Sue

 

[Jack Leach]

For your code, its (almost) as easy as selecting the database file you want
to reference by going to Tools -> References -> Browse...

Caveats: maintainence is a real pain. If you use an mde, you anytime you
update the mde file you need to re-reference it to the back end. If you are
comfortable using an mdb file for it then it becomes much easier, but if you
change the location of the library file you will need to re-reference it
again.

So it works well, as long as you don't change anything. And don't edit the
library file from a seperate frontend (even though you're technically allowed
to). To edit the lib you should close the current frontend, make sure no
other FEs are connected to it, then open it for editing, make your changes,
and go back.


As far as the objects go (forms/textboxes) I'm not sure of a great way to do
this. My preferred method is to save a template form in the database with
some boilerplate code behind it, then it's easy enough to import to another
db and use there as well.


hth
--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

 

[Stuart McCall]

For your code, its (almost) as easy as selecting the database file you
want
to reference by going to Tools -> References -> Browse...

Caveats: maintainence is a real pain. If you use an mde, you anytime you
update the mde file you need to re-reference it to the back end. If you
are
comfortable using an mdb file for it then it becomes much easier, but if
you
change the location of the library file you will need to re-reference it
again.

So it works well, as long as you don't change anything. And don't edit
the
library file from a seperate frontend (even though you're technically
allowed
to). To edit the lib you should close the current frontend, make sure no
other FEs are connected to it, then open it for editing, make your
changes,
and go back.

That's extremely wise advice. I can't imagine how much code I've lost due to
forgetting this (in the past - I've trained myself to never do it nowadays).

As far as the objects go (forms/textboxes) I'm not sure of a great way to
do
this. My preferred method is to save a template form in the database with
some boilerplate code behind it, then it's easy enough to import to
another
db and use there as well.

I do much the same, but store them in my library database. That way,
multiple apps can get what they want all from the same place. It's a bit
like using a resource file.

 

[Jack Leach]

I can't imagine how much code I've lost due to

forgetting this

Yes... and it's so tempting...

I do much the same, but store them in my library database.

Can you access these through Access? Or do you still have to import them
the usual way, just having one central location to store them...

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Stuart McCall]

Yes... and it's so tempting...



Can you access these through Access? Or do you still have to import them
the usual way, just having one central location to store them...

<snip>

For templates, the latter, but the one location thing is important IMO.
Ensures everything starts off on the same page, and I don't have to go
looking for stuff in other apps. Life's too short.

However it is possible to access working ('utility') forms/reports from the
'client' app. You just have to include a public routine in the lib which
will open the object. My lib file includes a calendar form, various forms to
get dates & date ranges, that kind of thing.

 

[Jack Leach]

However it is possible to access working ('utility') forms/reports from the

'client' app. You just have to include a public routine in the lib which
will open the object. My lib file includes a calendar form, various forms to
get dates & date ranges, that kind of thing.

Thanks Stuart, definately worth NOTING... <g>

Nice to know... I'll have to keep this in mind.. I've considered trying it
out in the past never did get around to it though.


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

 

[Sue L.]

For your code, its (almost) as easy as selecting the database file you want
to reference by going to Tools -> References -> Browse...

Caveats: maintainence is a real pain. If you use an mde, you anytime you
update the mde file you need to re-reference it to the back end. If you are
comfortable using an mdb file for it then it becomes much easier, but if you
change the location of the library file you will need to re-reference it
again.

Thanks Jack,

That's helpful. I'm using Access 2007. When I use their publishing wizard,
how do I make sure that my library database is there and correctly referenced
at my client's site?

I currently develop in a very different directory structure than I load the
runtime at the client site.

Do I understand correctly, that if I make an executable (accde) file of my
library, the link will be lost in my run-time code?

Thanks,

Sue L.

 

[Jack Leach]

Hmmm....

I've never used the publishing wizard, so I won't even go there, but as far
as general rules go...

Ideally if you distribute an app that requires a reference library, you
would distribute the reference in the same folder as the frontend of the
application, in the form of a dll file. Then you would, using whatever
install procedure you may have, register the dll file using regsvr32, before
the actuall application itself is run. This makes sure that the required dll
library is already installed to the windows registry before the app is
called. That's ideally... unfortunately you need vb6 or .net to create a dll.

I'm not sure how you would accomplish this for a accde file. The problem is
that the linked path of the library is stored inside your application, not
the windows registry. So when you open that app, if the library isn't in the
same place that it was when you developed, your app will have a broken
reference and all sorts of things may go wrong at that point. I'm not
positive how to make sure that when the app initially opens that you can
redirect the link to the library file, but you can take a look at the
following link to an extremely helpful article on the subject... and maybe
someone else has a better idea of how to accomplish this, because the link
explains a way to do it, but it is pretty difficult to make absolutely sure
it will work every time under all environments...

http://www.trigeminal.com/usenet/usenet026.asp


hth - hope someone else can give a better answer...

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

 

[Sky]

That's helpful. I'm using Access 2007. When I use their publishing wizard,
how do I make sure that my library database is there and correctly referenced
at my client's site?

I currently develop in a very different directory structure than I load the
runtime at the client site.

Do I understand correctly, that if I make an executable (accde) file of my
library, the link will be lost in my run-time code?

Thanks,

Sue L.

If you install the database library in the same folder as the front-end
database, Access will find it there if the original library path is
missing. (This is true even if the same folder is not where your
development library is originally stored on your own computer.)

Just don't get confused by having two copies of the library in both
places. (In that case, it uses the path that is explicitly listed in the
References.)

If you want to distribute a compiled front-end, you must first compile
the library, then reset the front-end reference from the uncompiled
library to the compiled library, and finally you can compile the front-end.

Steve