04-04-2011 05:43 AM
Hi,
I've created an access database for use in my project to log data.
So I was simulating a months worth of data to see how big the db file would get in a month - so as to not run out of space on my cRIO -, and it got to 6MB. After I did that, I used the Drop Table vi to delete all the tables...however, the file size did not decrease at all?
Now this worries me as I'm not sure what will happen in the field. Why is the file still so large with no data in it (apparently)?
Am I doing something wrong?
Any help will be appreciated.
Regards
Mark
Solved! Go to Solution.
04-04-2011 06:22 AM
Dropping or deleting the table from an MS Access database does not automatically free the space used by that table.
The only way I know to reduce the size of an Access MDB file is to open it with MS Access and run Tools -> Database Utilities -> Compact and Repair Database...
You need exclusive access to the MDB file when doing this...
04-04-2011 06:39 AM
As Phillip did mention, this issue is nothing with the Database Connectivity Toolkit. It is a general 'issue' with Access/Jet like it can be found out in a google-search which results in hits like this.
Please note that the behavior is exactly the same when working with Outlook Express/Windows Mail when deleting emails. Even if you empty your trash in Outlook/Mail, the size of the file on disk stays the same. If you select "Compress folders", the filesize will be reduced as expected.
Norbert
04-04-2011 08:24 AM
Thanks guys - I've only ever used SQL so this is pretty new to me. Plus that was in PC based software, never really worried about file size issues.
So there's no way to programatically do this within Labview?
04-04-2011 08:32 AM
You cannot do this with the Database Connectivity Toolkit, but implement it on your own using the ActiveX of Access.
See attached screenshot:
But please note that this approach needs unique access to the database file. So you must not access the same database file in parallel by Database Connectivity when compressing.
Norbert
04-04-2011 08:54 AM
Thanks, appreciate the help.