QDF file structure query?

I didn't include the key word 'transaction'. First sentence should read "...in a Q register transaction (say, ....)"

I'm not clear what your underlying problem is, but characters deleted from a field are no longer counted toward the limit.

You can key over data already in the field, you can append data to what's already in the field, or you can delete whatever data is in the field then enter new data. The maximum number of allowable characters is always the same, and Quicken does not "remember" any characters you delete from a field.

For example: if a field can hold a maximum of 10 characters and it currently contains 10 characters, you can not append another character to the existing data. If you delete one character from that field, you can then add one character to that field. If you delete all 10 characters from the field, you can then add 10 characters to that field. And if your keyboard is not in "insert" mode, you can key 10 new characters over the existing 10 characters. [Note: every "character" (including space and even unprintable characters) counts towards the max characters allowed.]

[When you use File > File Operations > Copy, Quicken will remove physical "records" (individual transactions, accounts, categories ... etc.) that have been "marked as deleted". Often when the user tells Quicken (and other software) to "delete" a record, the software just sets a flag in the record denoting that the record is "deleted" (marking the record as deleted) but the physical record remains in the file. A Quicken Copy will remove those "logically deleted" records. Quicken Copy does not deal with individual fields in records.

Hi John, not a problem, just a curiosity. What I meant was simply if I change ANY part of a transaction, even as trivial as changing one single letter in the memo field, and saving it back, is that entire record's storage no longer available until a Quicken copy is performed. My assumption is that the new transaction is now saved in it's entirety elesewhere.

I do not believe that is true. I believe that when you modify an existing transaction, it remains stored where it was before you modified it - and a Quicken Copy would do nothing to change that (there would be no space to recover).

But when you delete a transaction, it remains in the .QDF file (only now identified to Quicken as "deleted") ... taking up the same space it did before you deleted it (but it's still in the same place it was before you deleted it). That is when a Quicken Copy will help; the Copy processes your .QDF file record-by-record and does NOT copy logically-deleted records into the new file.

Frankly, I doubt that most users will have much need to clear out logically-deleted records from their .QDF files; Quicken itself can use as much disk space as you have available - and that disk space includes whatever space is needed for logically-deleted data.

One area where a user might have sufficient disk space, but still need to remove logically-deleted data is for things like Accounts, Categories, etc.. See this:

NOTE: While I agree that simply deleting a Quicken element, such as a Category, will not allow the user to add another Category if they have already reached the limit of 32768 categories. But I don't agree that the user must then "start a new Quicken file". I interpret that statement to mean "start a new file [from scratch]" and I don't think that's necessary for this situation. This is a situation where I THINK the Quicken Copy would solve the problem: the newly copied file should allow the addition of at least as many elements as were deleted from the old file. I've never come close enough to any of the Quicken "limits" to test my assumption.

I don't think so: it's really not a "new" transaction, it's the same old transaction with some different data.

Thanks John for the interesting post. It all reminds me of the days of entering 'garbage collection' routines in the early days (although that was for memory, not disk space.)

I recall running routines for reclaiming disk space. Is a Quicken transaction stored as a fixed length record regardless of how many characters are in the transaction?

I don't know.

There are data bases that use only sufficient space for the actual data - that is, that don't use fixed length fields. But Quicken is pretty old, so I suppose it's possible the Quicken data is stored in fixed length fields/records.