This weekend, I again tried to do some database programming. This time using Mobisystems. Of course it crashed, as has become now an obvious problem with the Lifedrive. But before it crashed, I began to notice something very interesting.
When I used the other database program, Smartlist, I noticed that the device would crash when it went to look for a database that was locked on the memory card. It would crash every time, until the database was brought into the main memory of the machine. It would crash only once or very rarely once that was done. I began changing fields in a new database written in Smartlist, this time limiting the number of additional files and storing them in lists instead, in order to minimize file access. This apparently made a differnce in Smartlist, however some linked files are unavoidable and this is when the problem would resurface.
Well, on Mobisystems, the crashes are fewer, since the program is using a sort of Access type relation, thus most of the data is stored within one database. However, wonder out to another database using the Lookup or link command and you find the same problems with crashing.
Well, the interesting thing that I have noticed is that if the file being accessed is on the Lifedrive (outside of the 64 mb section), then the crashes occur more frequently. This weekend I am going to try to place all of the databases into the 32mb portion of Ram not the extended 32mb, which is the disc drive and see if that makes a difference. My theory is that it may have something to do with the FAT-32 system. Since using Resco, I have been able to see where some of the programs are residing.
Are many of the files in the database programs reading the palm structure as a .PDB which is the classic palm file system , all linear and treated as a serial database, thus thwarting their abiility to assume that bits of files may be somewhere else, as in the disc drive? A possible solution could loom here.
LDD.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment