My gripe list- some unpredictable behaviours

I think DTPro is awesome. But here is a list I made while I am getting used to the program. A list of what I thought were either bugs or unpredictable behaviour.
I am a new user - gone through the forums to some extent. But if the topics are already covered, pardon me and kindly point me in the right direction.

  1. If I rename a file, it takes several seconds and upto a minute for the program to be responsive normally again. Why isn’t it instantaneous?
  2. Suddenly, a 739MB database after adding a few pages of text crept up to 1.34GB. why? Has it made an internal back up that caused it to double its size? I have it to do weekly backups and let it keep two copies of it.
  3. Continuing on 2, I verified the database. No errors. I asked it to backup and optimize. The file size did not change. So I don’t think that it is the interanal back up that is causing the size increase. or is it? Well, finally I asked it to rebuild the database assuming that would take it back to the original size. But alas, it has not. Still it is 1.34 GB. I have only worked on it for a couple weeks now. I am not sure how I would manage such an escalation in size as time goes by!
  4. well more annoying were:
    a) when it rebuilt the database, it tried to convert several file. For eg. I have an experiment folder that has prism graph files. When I dragged it into the database, it was showing the original prism icon and would hence give me an option to open it with prism. Now following the rebuild, those Prism graph files have been ‘converted’ into textedit files give me the option of opening them with textedit!!
    b) Again in my PDF library, I had several hundred PDF files and perhaps two dozens of them were in duplicates. A few days ago, I went through each of the duplicate ones (blue fonts), confirmed the existence of another good copy elsewhere and deleted the duplicate. Now in the rebuild, I expected it to remember all this and what it should contain. But hey, all those duplicates crept back in and made me work again for another half hour. That’s OK. But it can’t keep happening everytime one may have to rebuild their database. The expectation is it should make it exactly as before - if only more stabler and tighter. Is it unrealistic?
    5.Won’t it be nice to have selectable option where you can say which files DT pro should try to convert while importing. I understand that DTpro can search though meta data of unsupported files and that way it reading them as text files might expand its search base and perhaps the user might find better results because of that. But I would like to retain original file associations and if there is a way to do meta data search maintaining such association it would be fantastic. But still I think, there should be more preference based control on these behavior.
  5. It would be nice to have the ability to custom configure keyboard shortctus for certain actions like stop/play/forward/back etc on slideshows and full screen photoviews etc.

Thanks,
Spydr

You do know that the backups of the database are kept in the database file itself, right? If you look inside the .dtBase file you will see the backup folders, which are the same size as the database itself. If you have 3 or 4 backups, you could have 4 or 5 times the actual size of the DB.

This is why I think it would be a good idea to have the backups as another dtBase file in the same folder.

Because of this behaviour I have turned off automatic backups and am performing them manually. I daily move two DT Pro databases between home and work machines and with the built in backup scheme I am moving four times as much material as I need to and it takes four times as long times twice a day at the standard settings. I have great difficulty understanding the logic of storing backups in the same location as the original. There is a 'Destination preference but it does not appear to be operational. I love DT and I would love to use it’s backups but as it stands at present I cannot.

Take a look at a new DT Pro script. Select Scripts > Export > Backup Archive.

This creates the smallest possible (zipped) archive of your database. It contains only your database (no backup folders), and appends the backup date as YY-MM-DD to the database name.

This is great for transporting the smallest possible database file. But make sure your current database is sound (actually, the routine does run Verify and Optimize). It’s a good idea to make conventional backups, too. There’s another script that will do that to the location you choose.

Good to know that I am not alone! Thanks for verifying my suspicion that the size increase was infact due to a backup. Bill, I would test drive those scipts pretty soon and we will see how it goes!
Have wonderful weekend folks!