Backend reserve

[Thurlowe Riley]

I am starting a new project where there will be a back end mdb for the
tables and a front end for users. All this will be across a network or wan.
If the front end user looses his connection , I want the front end to be
able to store entries till the wan connections are reestablished and then
send the entries to the backend on the server. Before I start does anyone
have suggestions?

 

[StCyrM]

Hi Thurlowe

The Front End stores the values of the connection strings and the table names
in a system table called MSysObjects.

Therefore you don't have to do anything special to save these values as it's
already done for you.

Best regards

Maurice St-Cyr

Micro Systems Consultants, Inc.

 

[John Nurick]

Hi Thurlowe,

Working with front end and back end mdbs across a WAN isn't worth
trying. See Albert Kallal:
http://www.attcanada.net/~kallal.msn/Wan/Wans.html for why.

Possibly what you need is Replication. See the help topic and
http://support.microsoft.com/?id=282977 for more information.

 

[Ronald W. Roberts]

I am starting a new project where there will be a back end mdb for the
tables and a front end for users. All this will be across a network or wan.
If the front end user looses his connection , I want the front end to be
able to store entries till the wan connections are reestablished and then
send the entries to the backend on the server. Before I start does anyone
have suggestions?

I think Mr. Riley is talking about saving data users have entered if the
connection is down and not
the connection string as to how the connection is made.

What he is asking his program to do is look at the connection before a
new records is written or an
existing record is updated and save it to a local table vs updating the
real table across a network.
I don't know if MS Access has anything built in that can do or help with
this. My guess is you can check for various
error code to see if the connection is broken, but... there are so many
other problems a program can run into
if a link to the database is down that I don't think it is worth the
effort to even try. For example, none of your
queries, reports, combo or list boxes, or domain aggregate functions
will work if they are using a linked table.
It is not easy in code to change or correct all of that if a network
link goes down and if you could build a work
around, the effort may be more than the original application required.

My suggestion would be to spend your effort and money on creating a more
reliable or stable network.

Ron

 

[Albert D. Kallal]

For disconnected systems, replication is what is often used.

This means the salesman's goes on the road with his notebook. When they
return to the office, the database is "synced" with the main database. There
is very much like updating your palm pilot.

All new records the salesman enter are then replicated to the main database
(and visa versa happens...each notebook gets all new records that appeared
in the main data base). This actually means that orders from other
salesman's notebooks will "eventually" get to your notebook.

ms-access thus does support what is called replication. Thus, for cases
where the system will be disconnected, and you have a lot of related tables,
it would be too much work to "code" this by hand, and thus replication does
all this work for you (and thus is a possible solution here).

Replication used to be a very high end feature of only a few big bucks
database systems, it is remarkable that the little desktop JET engine for
ms-access has had this feature for years now...