Thank you for your replies. I guess I may be out of my depth if the problems and changes you mentioned occur to the database in the future.It IS for a porter system, so direct patient contact would probably be limited to patients who need porters. Even so, hospitals are supposed to be run so that all parts integrate as smoothly as possible and the OP did mention it was a 20-user system, so that is potentially a lot of places where porters might be needed.
I am praying this is not for the NHS.
I can see patients falling through the cracks if the system is not robust enough.
Well maintaining a database includes dealing with users who report an error, resolving the error and if necessary fixing the database so it doesn't fail again for that issue. It also includes modifying the database to provide additional features requested by users. Hence the developer/service engineer needs to understand the database, and have practical skills most likely honed by many years of doing such work.Well as I am not a veteran to handling an active access database I am not sure what "Maintaining" a database would entail.
I have not supervised one over a lengthy amount of time to know what would need to fixed or "maintained".
Assuming that my database is stable and won't crash then I don't see any other problems occurring apart from bloating.
The term "maintain" is very broad so if you'd like to explain what exactly maintaining a database would be then maybe I would be able to tell or not if I am out of my depth.
Thank you for giving a precise reply. But let's say the system is stable and does not crash? And also does not require any new features?Well maintaining a database includes dealing with users who report an error, resolving the error and if necessary fixing the database so it doesn't fail again for that issue. It also includes modifying the database to provide additional features requested by users. Hence the developer/service engineer needs to understand the database, and have practical skills most likely honed my many years of doing such work.
But let's say the system is stable and does not crash? And also does not require any new features?
Well I don't know what windows services you use, but what if there's a network issue and a particular drive goes off line, or the internet stops working. Maybe you use FTP services, and something changes so FTP no longer works. There might be a windows update that cause Access to fail. We have had a few doozies of that nature. Who knows?Thank you for giving a precise reply. But let's say the system is stable and does not crash? And also does not require any new features?
Does uploading the backend to an SQL server mean I need to install extra software? Unfortunately I can't do that if so.Hi omarrr128. I had a similar situation. I won't repeat all the good advices above. My solution was this: when users click on the link to start the database it calls a script that copies the frontend to the users' profile. This way you can continue to develop and you deploy to a hidden folder where your script will pick it up.
As for the backend, because it's used 24/7 the only good move is upload it to a SQL server. There are good free ones: Postures and MySQL.
I don't have a 24/7 issue but I needed to do regular compact/repair/backup. So, in the front end I created a hidden form that is called on start up. It has a timer event set to 5 minutes. The code behind checks for the existence of a text file where the backend reside. If file exist it warns user to exit the database in the next three minutes, or prevents the frontend from starting up, with a 'maintenance' message.
And for speedy compact and repair I bring the backend to my desktop, compact/repair, upload the backend, delete the maintenance text file, then rename my copy to add a date and archive it elsewhere. All this by script. But wait untill the backend's lockfile is gone.
Are you able to give an example of the script that would copy the front end to the users profile?Hi omarrr128. I had a similar situation. I won't repeat all the good advices above. My solution was this: when users click on the link to start the database it calls a script that copies the frontend to the users' profile. This way you can continue to develop and you deploy to a hidden folder where your script will pick it up.
As for the backend, because it's used 24/7 the only good move is upload it to a SQL server. There are good free ones: Postures and MySQL.
I don't have a 24/7 issue but I needed to do regular compact/repair/backup. So, in the front end I created a hidden form that is called on start up. It has a timer event set to 5 minutes. The code behind checks for the existence of a text file where the backend reside. If file exist it warns user to exit the database in the next three minutes, or prevents the frontend from starting up, with a 'maintenance' message.
And for speedy compact and repair I bring the backend to my desktop, compact/repair, upload the backend, delete the maintenance text file, then rename my copy to add a date and archive it elsewhere. All this by script. But wait untill the backend's lockfile is gone.