Imagine a remote system where there are a large number of MS Access database apps (a lot created by 'laymen'), many poorly defined / designed / produced.
(You may find this easy to do).
Some are having problems with exceeding the 2gb max database size, which in turn creates issues of locked sessions / corruption etc.
They frequently need 'manually' compacting. (Yep - I can go through every one, and add code to do just that, but, that's in future - one step at a time).
An easy, double-clicked VBScript can be created to compact these databases (following backing up, checking database is closed, various error checking within the script).
This works fine, but is a little 'loose'. E.g. on failure, there could be better 'clean-up' etc., but scripts aren't the best for this process.
So, I decided to try encapsulating this in an MS Access app. (now using a pre defined list of applications, with their paths, storing who / when compacted, pre & post sizes etc.).
All databases can now be compacted from this single, centralised app.
Both the MS Access app and the 'script' method will be run from a client laptop, processing MS Access databases on a remote network server.
I know that the laptop doesn't even need MS Access installed to be able to perform that script 'compact' (as Windows has a DB 'engine' installed by default).
It of course DOES need MS Access to run the MS Access 'compact' application.
Question - (and it may sound silly, but no-one knows what they don't know):
Does the laptop cpu / memory undergo the same amount of work to perform the compact process via it's 'script', as much as it does via it's MS Access application?
(Here's where it's fuzzy for me - I 'get' that the laptop 'does it all' for the MS Access application that performs the compact - dragging all data locally, from the network, but is the script command 'passed' to the network, or, is the laptop still performing the actual compact process itself (dragging ALL data across from the network - onto the laptop).
I hope I've been clear enough to define the problem accurately, if not - please let me know.
Thanks for any pointers on this.
ATB,
Darrylle
(You may find this easy to do).
Some are having problems with exceeding the 2gb max database size, which in turn creates issues of locked sessions / corruption etc.
They frequently need 'manually' compacting. (Yep - I can go through every one, and add code to do just that, but, that's in future - one step at a time).
An easy, double-clicked VBScript can be created to compact these databases (following backing up, checking database is closed, various error checking within the script).
This works fine, but is a little 'loose'. E.g. on failure, there could be better 'clean-up' etc., but scripts aren't the best for this process.
So, I decided to try encapsulating this in an MS Access app. (now using a pre defined list of applications, with their paths, storing who / when compacted, pre & post sizes etc.).
All databases can now be compacted from this single, centralised app.
Both the MS Access app and the 'script' method will be run from a client laptop, processing MS Access databases on a remote network server.
I know that the laptop doesn't even need MS Access installed to be able to perform that script 'compact' (as Windows has a DB 'engine' installed by default).
It of course DOES need MS Access to run the MS Access 'compact' application.
Question - (and it may sound silly, but no-one knows what they don't know):
Does the laptop cpu / memory undergo the same amount of work to perform the compact process via it's 'script', as much as it does via it's MS Access application?
(Here's where it's fuzzy for me - I 'get' that the laptop 'does it all' for the MS Access application that performs the compact - dragging all data locally, from the network, but is the script command 'passed' to the network, or, is the laptop still performing the actual compact process itself (dragging ALL data across from the network - onto the laptop).
I hope I've been clear enough to define the problem accurately, if not - please let me know.
Thanks for any pointers on this.
ATB,
Darrylle
