Internal Backup causes database bloat

Keeping everything that has ever been entered into a database internally even when it is deleted seems an awful waste of space, especially when you are trying to backup over a network. I’m not opposed to keeping an archived copy “just in case”, but I would prefer to keep it in another place. I often use DT several times per day, going back and forth between desktop and portable machines. Each time I have to synchronize the db’s.

DT Professional’s ability to use multiple db’s has helped because I can break them down to smaller files, but it doesn’t take long to get big files again, especially with those internal backups.

Here’s an example of the problem. I was experimenting the other day with adding a group of jpg’s to a db. They were about 1mb each and I added about 20, so the small db I was using grew quite a bit at one jump. I decided there was no reason to use that much space, so I made a contact sheet in Photoshop that took only a few kilobytes and added that to the db. So, then I was able to get rid of the 20mb, right? No way! It’s still in there, of course, because of the internal backup.

I know there’s a workaround. Just export the stuff to files and then make a new db and import it again and the bloat is gone. Yeah, but I’ve run into a problem with that procedure. Sometimes DT fails to import some files, especially, it seems, pdf’s.But not always the same ones. I have done this particular procedure before on this database, and this problem has appeared before, but always to pdf’s I felt I could live without, but this time a whole bunch popped up on the failed list and some of them were ones I didn’t want to let go of.

I guess I have two questions here:

What are the chances of getting an external backup system for archiving old versions of the db?

Does anybody have an idea why exporting and importing pdf files would work with a particular file one time, but not the next?


An external backup (see preferences) will probably not appear before v2.0. To reduce bloat, you could either disable all backups (but this is definitely not recommended) or reduce the number of them. Or use “Tools > Backup & Optimize”.

But #2 is difficult to tell. Sometimes the PDFKit of Tiger fails (or even crashs), maybe that’s the reason?

I’d like to mention again the virtues of Christian’s Backup Archive script. It’s available at DT Pro’s Scripts > Export >Backup Archive.

[1] It allows you to choose the destination of the backup on the fly, e.g., an external drive.

[2] It automatically runs Verify & Repair and Backup & Optimize.

[3] It produces the smallest possible backup, including the main database and the database Files folder, but no internal Backup folders.

[4] It then compresses the database and adds the date to the filename.

[5] It’s already available, easy, and let’s the user decide when to do a backup, e.g., at break time after a heavy session of editing.

[6] It’s the most compact way to send a database to a friend via email, or to post on your Web site for download by others.

If you need to use a backup archive, double-click on it to expand the database. Then double-click on the expanded database to open it under DT Pro. To make it your default database, select File > Database Properties. Check “Default” on the Database Properties panel. Note: As you continue to use this database, it will create internal Backup folders inside the package file.

Depending on how you do the synchronization it’s possible to exclude Backup* folders inside the database package (e.g. using a simple rsync script).

Just wanted to mention that as an alternative to Bill’s useful Backup Archive script suggestion. Which reminds me… is there a reason the script excludes Settings.plist file from the archive?

No but the settings.plist contains only a few user interface-specific preferences. Nothing really important.

What are the WindowState values used for? I was wondering if they have anything to do with which windows are reopened at startup when “Preferences>General>Startup: Open windows that were open on quit” is set.

And maybe this is somehow related:

I’ve noticed a problem with windows not being reopened correctly when I switch databases from a running DTP (1.1beta11) using Open Database… or Open Recent from the File menu. If I quit first, then launch DTP with a different database then its previously open windows are properly reopened.

Can anyone else confirm that problem before I submit a more detailed bug report? Thanks.

I’ve had the same kind of problem with exporting/importing pdf’s. So, finally, I decided to keep my pdf’s outside the database, in a single finder folder, with an attached script (action index). Each new pdf is dropped into this folder, and the finder prevents me from having duplicates. DTPro indexes the new files. I keep a backup of the DTPro group hierarchy (kind of a catalog). The database is lighter, launches faster. If the database got damaged, I could still create a new one, reindex my pdf’s, and recreate the group hierarchy from the catalog (with the help of Applescript!). I would be very interested to know if someone has different solutions for these


I couldn’t reproduce this over here - which startup preference do you use?

“Open windows that were open on quit” is set.

A simple, incomplete explanation:

Windows that open when opening a database with DTP running will use window locations from the database that’s just been closed.

It’s easily reproducible here and I’ll send some specific details later. I’ve got too much work in progress to fuss with it right now.

Size/Position of windows is currently not database specific.