Re: Access DB grows too fast.
From: Nate Clark (ntclark_at_attglobal.net)
Date: 06/28/04
- Next message: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Previous message: William \(Bill\) Vaughn: "Re: "Timeout expired. " when using Fill Method"
- In reply to: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Next in thread: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Reply: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 28 Jun 2004 22:55:19 GMT
Hi Bill,
Thanks very much for the response.
I'm not deleting and/or updating rows.
These are pure inserts where no like rows existed before.
I have tried everything I can think of and still get the same result. If
I try to insert these rows using SQLPrepare/SQLExecute from C, I get
about 40MB of something "extra" for every few MB of new data that I load
and can only get rid of this extra space by Compacting (an automated
compact is not practical after import as I expect that alone will wipe
out the performance gain I get from going to C (which, BTW, is pretty
significant).
All of this makes me wonder if there is something different between the
ADODB.Connection made in the VB side and the SQLDriverConnect connection
I get on the C side.
I looked but cannot find a way to obtain the connection handle from the
ADODB.Connection so I could pass that connection to the C Code. If I
could, I could prove or disprove that this difference (if any) is the
culprit (or if I've caused some kind of "multi-user" situation by
creating an "extra" connection to the db)
William (Bill) Vaughn wrote:
> Nate,
> Unlike SQL Server (or most other business-class databases), Access/JET
> does not recover space lost when rows are changed or deleted. Any alteration
> of the database results in the original row being marked for deletion and
> the new row (even if it's exactly the same) being added. Add a row, you get
> one more row. Change the row and now you have an additional row. Delete a
> row and the row remains. It's only after you compress the database are these
> extra rows removed and then only in the process of locking down the file and
> copying only the "active" (undeleted) rows.
>
>
- Next message: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Previous message: William \(Bill\) Vaughn: "Re: "Timeout expired. " when using Fill Method"
- In reply to: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Next in thread: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Reply: William \(Bill\) Vaughn: "Re: Access DB grows too fast."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
|