synchronisation / replication problem

[edster]

Hi,

I have a central database with multiple users on a fixed network. However now there is a need for an external service engineer to enter his service data into the database. He will very rarely be in the office so wants a way of doing this remotely.

I'm looking for a solution really, my first thought was replication and he could email his file back to the office it could be updated then emailed back however apparently this will create new guid replication number which will mess up the database?

Second thought was standalone database and he could export the data to xls file and then email it to be imported into the main one?

Any thoughts?

 

[DCrake]

Alot will depend if he is adding records to a table that contains autonumbers or primarykeys. If he is simply updating records then the issue is as important. You would however have to consider which record has the most uptodate information. It would be better if he had access to the database via terminal server or something similar. That way he can interact with the live data, thus no need to worry about conflicts.

David

 

[edster]

Thanks david, I've suggested this to the company however they have security resevations as he is a sub contractor!

 

[DCrake]

I would suggest knocking together a very simple data capture form based on his own paper record and get him to enter the data here. Then write code to import the data in your main tables.

How does he get the job specs if he is not in the office most of the time?

David

 

[dfenton]

I have a central database with multiple users on a fixed network. However now there is a need for an external service engineer to enter his service data into the database. He will very rarely be in the office so wants a way of doing this remotely.

I'm looking for a solution really, my first thought was replication and he could email his file back to the office it could be updated then emailed back however apparently this will create new guid replication number which will mess up the database?

This is correct. Replicated databases have to be synchronized IN PLACE once data has been edited in a new replica. You can't copy or email them back and forth.

Second thought was standalone database and he could export the data to xls file and then email it to be imported into the main one?

Do you have a Windows server? If so, set him up with remote access via Windows Terminal Server. This is by far the easiest way to do this. It requires not code whatsoever, and he'll be editing the same data file as everyone else.

I've been doing replicated Access apps since 1997, and when there's a Windows server involved and fixed locations, or remote users who have an Internet connection when they need to work, I always choose Terminal Server over mucking with indirect replication. I know perfectly well how to do it, but WTS is so much easier and so much more reliable it's not worth doing anything else. It's also cheap.