[Tech Support] Sorry about this ...

[dancefloorlandmine]

We're currently having joy with a database that's playing up, and the person to blame for credit with creating this has decided to change the way it's set up. Previously, each volunteer had a desktop shortcut to the server copy of the database on their PC (we're ruining Windoze 2K, btw). However, the new cunning plan is to put a front end .mdb on each PC, and replace the current shortcut with the appropriate for the new database.

Copying the .mdb to the individual pcs is no problem (nice shared C: drives, stroke, stroke), but she's in a bit of a quandary with regard to how to be able to manage the shortcut change, without requiring someone to wander around each PC and do it by hand (there are several PCs in Macclesfield and Bristol). If I was going to take the time, I'd use VNC to do it remotely, but I'm not in the office next week (due to the joys of revision).

I've scavved a couple of vb scripts that can create and delete shortcuts on the local PC, but not quite sure how to get them to run remotely on the other PCs. Alternatively, would a simple command line "erase \\machine01\c:\blahblah\desktop\blah.lnk" do the job in a reliable fashion. And would a similar copy instruction do the trick for adding the link (once a sort of template shortcut had been created)?

You see, I truly know nothing! And I'm tired.

Comments

[d-floorlandmine.livejournal.com]

Not missing anything - just that, to coin a phrase, "our users have varying levels of ability"¹, and wouldn't all be able to open the database without a shortcut in the middle of an otherwise almost empty desktop. Hence, unfortunately, the need for shortcuts.

At the moment, it's a bit of nightmare:
User on PC -> Access database on local server -> SQL server in London

The plan is apparently to move to:
User with Access db on local PC -> SQL server in London

Me, I'd probably prefer:
User with Access front end on local PC -> SQL on local server (with data capture queries which echo the captured information to the core research database in London - or build the research database so that it queries the local data when the queries are run). That would at least proof the data collection against VPN glitches, but I'm not technically involved in the development of this one - just the fire-fighting ...

¹ One of the guys on our support helpdesk liked that one so much he decided he was going to make a note of it as being one of the most diplomatic way of referring to lusers he'd heard.

[thepaintedone.livejournal.com]

Managed to miss this before my other reply.

Using Access to stage a SQL connection is about as bad an idea as I can think of. Access is an horrendous SQL client unless you set it up very carefully.

I'd say that your best setup, as you seem to agree, is Local client (written in whatever) > Local SQL server <> Merge Replication to central distributiuon server.

As long as you code the client carefully, this will let you do inserts and edits at any site, and all sites will have all the data. All the sites can also run independantly if the connection goes down.

I put together a very similar setup with offices in 6 different countries. Access clients talking to local SQL servers, each server dialled in overnight to the central server to exchange all the updates. Worked very well.