Hi

I have designed a set of Access2000 applications, and split them afterwards.
So I have now p.e. :
App1.mdb and App1_be.mdb;
App2.mdb and App2_be.mdb, where App2.mdb links some tables from App1_be.mdb;
App3.mdb and App3_be.mdb, where App3.mdb links some copies of tables from
App1_be.mdb from memory stick (App3.mdb and App3_be.mdb are located in
high-secure computer without acess to LAN or internet).

We may forget about App3 at moment. App1 and App2 were designed as separate
applications, because they have different users in general, and for better
perfomance (there are some big tables in both of them).

Now after splitting App2.mdb has linked tables to App1_be.mdb and
App2_be.mdb. Whenever I send a new version to user, he has to select
manually tables from one BE in Linked Table Manager and relink them, and
then repeat this operation for tables from another BE - not very comfortable
way, and it's easy to make some mistake.

My question:
When I merge both App1_be.mdb and App2_be.mdb to a single BE, will this
cause some problems (like performance drop)? I.e. are BE files only data
containers and most of data processing is done in FE, or is data processing
done mainly in BE?



--
Arvi Laanemets
( My real mail address: arvi.laanemets<at>tarkon.ee )

> My question:
> When I merge both App1_be.mdb and App2_be.mdb to a single BE, will this
> cause some problems (like performance drop)? I.e. are BE files only data
> containers and most of data processing is done in FE, or is data
> processing done mainly in BE?


Since you're not actually increasing the size of any given table, having
more tables, or more data in a single container as a general rule does not
affect performance a whole lot (in fact I don't think it makes any
difference).

Remember of regardless of what you finally do, you should as a general rule
after you split your databases build, design, develop, and implement some
automatically re linking metheod.

In other words forcing your users to learn and use the linked table managers
for their application is asking them a bit much. my customers never have to
re-link their data files.

So, you should write some software that checks for "bad" links and if
they're not correct it automatically fixes and re-links for you...

You can use the code here to re-link.

http://www.mvps.org/access/tables/tbl0009.htm

We often combine the above code with also the following code here:
file open dialog:
http://www.mvps.org/access/api/api0001.htm

Furthermore if you ever plan to use a runtime environment, or that you hide
the MS access interface, it's a little much to expect users to learn, know
about and deal with linked table manager.

In fact, just even the writing up of your support instructions on how to
connect to the back end can extremely simple fight if you build in a
solution that links for you (and furthermore few use code, then the user
will not be prompted for each table one at a time). the linked table manager
stuff is for developers and software professionals, not something that
you're an user should ever have to deal with...

I've been meaning to post a complete solution that links on startup for you,
but most developers at one time or another have simply resorted to using the
above two code examples as a starting point for their automated linking
system.

The beauty of setting up a really nice automated linking system, is this
makes deployment of new software an snap as they just simply have to
download the software. if you provide a script of some type to copy it into
the correct directory then you can make one button update for your customers
like the following screen shots:

http://www.kallal.ca/ridestutorialp/upgrade.html

(the above is access....And that is all the customer has to do when I send
them a new update).



--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)

A lot of thanks.

I have considered automatic linking myself too, but at moment there are some
tasks more urgent, and have to work at them on weekends and evenings anyway.
There is one user with administrative rights, whom I can trust, and who will
do all updating on site and can contact me when he has some problems, but I
don't think it as a good permanent solution.

The links you provided are great help for sure, as I havent written such
kind of code before, and 'bicykle inventing' may be too time-consuming way
to get new experience.

Every FE in my applications has a SetUp table, where some default parameters
for this FE are stored (the user can determine which filters are applied to
forms on open etc.). I think it will be an appropriate place to have a field
where the path to BE file will be stored.


--
Arvi Laanemets
( My real mail address: arvi.laanemets<at>tarkon.ee )


"Albert D. Kallal" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> My question:
>> When I merge both App1_be.mdb and App2_be.mdb to a single BE, will this
>> cause some problems (like performance drop)? I.e. are BE files only data
>> containers and most of data processing is done in FE, or is data
>> processing done mainly in BE?
>
>
> Since you're not actually increasing the size of any given table, having
> more tables, or more data in a single container as a general rule does not
> affect performance a whole lot (in fact I don't think it makes any
> difference).
>
> Remember of regardless of what you finally do, you should as a general
> rule after you split your databases build, design, develop, and implement
> some automatically re linking metheod.
>
> In other words forcing your users to learn and use the linked table
> managers for their application is asking them a bit much. my customers
> never have to re-link their data files.
>
> So, you should write some software that checks for "bad" links and if
> they're not correct it automatically fixes and re-links for you...
>
> You can use the code here to re-link.
>
> http://www.mvps.org/access/tables/tbl0009.htm
>
> We often combine the above code with also the following code here:
> file open dialog:
> http://www.mvps.org/access/api/api0001.htm
>
> Furthermore if you ever plan to use a runtime environment, or that you
> hide the MS access interface, it's a little much to expect users to learn,
> know about and deal with linked table manager.
>
> In fact, just even the writing up of your support instructions on how to
> connect to the back end can extremely simple fight if you build in a
> solution that links for you (and furthermore few use code, then the user
> will not be prompted for each table one at a time). the linked table
> manager stuff is for developers and software professionals, not something
> that you're an user should ever have to deal with...
>
> I've been meaning to post a complete solution that links on startup for
> you, but most developers at one time or another have simply resorted to
> using the above two code examples as a starting point for their automated
> linking system.
>
> The beauty of setting up a really nice automated linking system, is this
> makes deployment of new software an snap as they just simply have to
> download the software. if you provide a script of some type to copy it
> into the correct directory then you can make one button update for your
> customers like the following screen shots:
>
> http://www.kallal.ca/ridestutorialp/upgrade.html
>
> (the above is access....And that is all the customer has to do when I send
> them a new update).
>
>
>
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
> (E-Mail Removed)
>
>