Q: Updating Access databases (and back)
> Here is my situation. I have a database that is being used in each of 7 =
> stores, as a nightly event, I have to synchronize the DB between all =
> stores (The main store holds the master tables, and all of the others =
> hold a set of "daily" tables). I need to figure out how to have my =
> program export the "daily" files to a file which can then be sent to the =
> main store. The main store must then append these files to the master =
> tables. After all stores have appended the tables, the main store will =
> call back out and send the master inventory list which must then be =
> imported into the databases at each store. All of this is a bit out of =
> my reach, but the hardest part is yet to come. Each store has an =
> inventory list that also contains the inventory from other stores. So, =
> when the other stores send this table, a simpl append will not do, the =
> main store must update each stores quantities within the inventory =
> table, without hurting the inventory from other stores, so it can update =
> them later.=20
> 
> Ugh....  I also have not the slightest clue as to how to achieve the =
> dial up connection. should I approach this as a dial up networking =
> connection? Or would I be better off using MSComm, and doing a file =
> transfer?
Brennon; Brennon@Selectos.com
A:
Well, I have some suggestions but remember that I can only talk from 
my background. There will be always better solutions but this is what 
I think right now (without testing it).
I work with Access so if other databases can do the same???

Exporting values is not very difficult. The best way to do it is 
writing the value's to an ascii-file. Use a query to set the relevant 
records.
Appending an ascii file to a database is also very simple. 

Make in the table's a field where you can set a department 
identification. This way you can only append the relevant (store) 
records to the master.

You can use a telephone line to transfer the data (ascii files are 
easier to send and to check).

But this way you have a lot to worry about. First you stores have to 
send it to the master. Second the master have to do the appending. 
Third: the master have to send the updated data to the stores. 
Fourth: the stores have to appand the updated data to the 
store-database. You have to make something on the server side 
(master) and on the client side (stores). 

store 1-7 -> sending data
master -> appending & update
master -> sending data to store 1-7

All this have to be timed. (Do you know when store 7 is ready with 
sending so that the master can start the appending?)

I don't know if the stores have an internet connection? If so you 
can do the whole action from the master. With FTP the master can get 
the files from the stores; do his thing and then send it back. It is 
easy to secure. And it is easy to program.
You can then get the whole database from each store; do some 
appending to the master and then send it all back afterwards.

master gets store 1
master append data
etc until store 7 is done

sending back data to stores

The hard part is not to identify each store (you can do it by just 
adding a store-identification number to the data). It is the transfer 
from the store to the master and back which is not easy.

Of course (I just think about it) instead of FTP you can use also a 
telephone line: master calls store 1; gets the data; do his thing; 
calls store 2 etc; and at last send the data back. But I have no 
experience with this kind of data-communication.
Try to make all the actions start from one place; this way you don't 
have to worry about timing.

If you use on all pc's win95 you can use the dialup; set a mapping to 
the store data and let the master do the updating. I only have 
expercience in mapping to another drive/computer and do some 
transfers. it works fine. But I don't know what if this is not 
faster/slower then a filetransfer.

Well it's just an idea. If you want some examples about access and 
exporting etc data then look on the url


http://www.kather.net/VisualBasicSource/msa/msaindex.htm

I hope it helped a bit. If you want more inof just let me know and I 
can see if I can do something about it...

Return