Ahh, the joys of Access. I've been deving in Access since version 2 and still do so on a daily basis despite repeated attempts to leave it behind forever.
First up, I think the advice above about shortcuts will do you fine, it's just an .lnk file which you can create, copy, delete like any other.
With regards to the changes, what you were doing before is very bad and wrong and as you've mentioned will corrupt the hell out of the MDB file on a regular basis.
With regards to getting the client out to the users. I would advise creating a folder on every PC (e.g. C:\Database ) and setting up a login script to copy the client from the file server to there, with a -y to overwrite without prompting, whenever they log in. A batch file on a file share so they can also manualy update can be usefull too. You can then create a simple desktop shortcut to the client. I tend to put a label on the main menu, with the date and time I released the client, so I can get a user to easily read it off to me so I can check what version they are running. If you do an automated copy though, watch out for the folder permissions. If you are hot desking you can get a situation where a new user doesn't have permission to overwrite the file that was put there by the previous user, as login scripts run with the users credentials.
As a very strong recomendation, deploy the client as an MDE. This has several advantages.
1. The users can't open it in design mode, so they can't screw around with things. 2. It's a lot smaller so it's quicker to copy down to the client PC. 3. The VB is pre-compiled so it runs noticably faster than an MDB.
Another tip. If you buy one copy of the developer edition of Access (well office), you can deploy the runtime edition, license free, to as many workstations as you like. This means you can buy a cheaper copy of Office and save you a stack of cash, very usefull for a chairty I'd imagine. For my 50 users we saved a couple of grand doing that. It also makes it impossible for the users to screw around with your databases! Work's very well in conjunction with MDE clients.
Incidentaly, switching to a SQL backend for access, while doable, is not nearly as easy a task as you might think. I've done it once before, and am doing it again now. Unless you have designed your system very carefully to expect this (v.unlikely) you have to essentialy re-build the entire thing. In fact what you mostly have to do is replace all the built in access functions with your own code modules. E.g. instead of having a bound form, you write a VB routine to populate the unbound form for you. You can't just put the data into a SQL server, then move the linked tables to that instead of an Access back end. The access client has no concept of proper SQL procedures, and if you allow it direct access to your SQL backend (i.e a linked table) it will bollux it up completely and performance could well be worse than with an access backend. e.g. Access will still copy the entire table down to the local client, and process it there, rather than letting the SQL engine do the work for it. It'll put cursors and locks all over the table while doing it as well! Linked tables to a SQL server is v.bad.
Without wishing to tread on your dev's toes. I've been doing exactly this sort of thing, to pretty horrendous depth, for many years now. So if you need any help or pointers on Access, drop me a line.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
First up, I think the advice above about shortcuts will do you fine, it's just an .lnk file which you can create, copy, delete like any other.
With regards to the changes, what you were doing before is very bad and wrong and as you've mentioned will corrupt the hell out of the MDB file on a regular basis.
With regards to getting the client out to the users. I would advise creating a folder on every PC (e.g. C:\Database ) and setting up a login script to copy the client from the file server to there, with a -y to overwrite without prompting, whenever they log in. A batch file on a file share so they can also manualy update can be usefull too. You can then create a simple desktop shortcut to the client. I tend to put a label on the main menu, with the date and time I released the client, so I can get a user to easily read it off to me so I can check what version they are running. If you do an automated copy though, watch out for the folder permissions. If you are hot desking you can get a situation where a new user doesn't have permission to overwrite the file that was put there by the previous user, as login scripts run with the users credentials.
As a very strong recomendation, deploy the client as an MDE. This has several advantages.
1. The users can't open it in design mode, so they can't screw around with things.
2. It's a lot smaller so it's quicker to copy down to the client PC.
3. The VB is pre-compiled so it runs noticably faster than an MDB.
Another tip. If you buy one copy of the developer edition of Access (well office), you can deploy the runtime edition, license free, to as many workstations as you like. This means you can buy a cheaper copy of Office and save you a stack of cash, very usefull for a chairty I'd imagine. For my 50 users we saved a couple of grand doing that. It also makes it impossible for the users to screw around with your databases! Work's very well in conjunction with MDE clients.
Incidentaly, switching to a SQL backend for access, while doable, is not nearly as easy a task as you might think. I've done it once before, and am doing it again now. Unless you have designed your system very carefully to expect this (v.unlikely) you have to essentialy re-build the entire thing. In fact what you mostly have to do is replace all the built in access functions with your own code modules. E.g. instead of having a bound form, you write a VB routine to populate the unbound form for you. You can't just put the data into a SQL server, then move the linked tables to that instead of an Access back end. The access client has no concept of proper SQL procedures, and if you allow it direct access to your SQL backend (i.e a linked table) it will bollux it up completely and performance could well be worse than with an access backend. e.g. Access will still copy the entire table down to the local client, and process it there, rather than letting the SQL engine do the work for it. It'll put cursors and locks all over the table while doing it as well! Linked tables to a SQL server is v.bad.
Without wishing to tread on your dev's toes. I've been doing exactly this sort of thing, to pretty horrendous depth, for many years now. So if you need any help or pointers on Access, drop me a line.