-----BEGIN PGP SIGNED MESSAGE----- At 05:32 PM 10/26/98 -0500, Ira wrote: > <snip - header stuff and original post extract> > >Suppose CFT-Win Ver 2.32 is the very last 16-bit program I will >release. The data files will always be compatible for any future >Ver 2 updates. So even if you had a Ver 2.40 you should be able to >still use the data files >with 2.32. <Hal notes> This is good news. Not being able to use the same data files between ver 2.XX and 2.YY would be disappointing and would in theory necessitate a bump in the version number. The point I'm hopefully making in this suggestion is that if one does freeze 16-bit CFT-Win at 2.32, that no matter how many iterations and versions of the 32-bit CFT-Win95/98/NT occur, that there be a provision to as painlessly as possible move the data from that last 16-bit version to whatever the current 32-bit version might be. >Ver 3 is entirely different, however, and to migrate backwards from >Ver 3 to Ver 2 would necessitate a GEDCOM transfer. Can be done, but >won't be fun. Hmmm. I'm thinking along the lines of being able to import and merge data from a 16-bit laptop running CFT-Win Ver 2.32 to any and all future versions of CFT-Win, but let's look at a hypothetical bi-directional transfer. Say my "real" database is on your latest 32-bit version on a desktop PC. I'm going to visit my Great Aunt in Massachusetts and I want to take my 16-bit laptop and a handscanner to record and acquire data. The sequence would be: 1) GEDCOM out a snippet of the "real" database, relating to the family member I'm planning to visit or in whom I am interested, from the 32-bit desktop system. I just need enough fields from the selected records to know with which entries I'm dealing and to provide a reference (the record number) to support a merge going back the other way. 2) Create a dummy database in CFT-Win Ver 2.32 on the laptop and import the GEDCOM file. 3) Do the visit with the laptop and handscanner and scan in relevant certs and docs, and key-in some of those keen family stories. 4) Return home and merge the 2.32 database, complete with scanned images and such, with the "real" 32-bit database on the desktop system in such a way as to: a) retain the existing data in records common to both the slimmed down (reduced number of fields) Ver 2.XX file and the fleshed out 3.XX file, and b) retain the links between the "starter" records common to both the 2.XX and 3.XX versions and the new records, as well as between the new records themselves. >I suspect that even by another year or two the Win 3.1 laptops will >begin to become as extinct as DOS. I did notice an immediate 90% >plus switchover to windows from DOS when I released my first Windows >Version. I suspect the same has happened with Win95/98/NT but has >been more invisible to me because I never actually sold them as two >seperate products. I don't know that the CFT-Win user base, especially that portion outside the US, has transitioned from Win3.1 -> Win95 in as radical a fashion as was seen with DOS -> Win 3.1, where there were a number of compelling reasons to upgrade. That doesn't mean that resources shouldn't be focused on continued application develop along only 32-bit OS lines. However, if and when a 16-bit user does upgrade, importing their existing data from that last 16-bit version to whatever the current 32-bit version is at the time should be made as painless as possible. Regards, Hal Ferguson 70521.1563@compuserve.com <<Digitally signed with PGP to allow source and content authentication by recipient. Get my public key by sending e-mail to pgp-public-keys@keys.us.pgp.net, subject MGET 1024/7F0EA10D, or at PGP key-server http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x7F0EA10D.>> -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: cp850 iQCVAwUBNjUPXRH/x85/DqENAQHiigP/ZDsAsFBmQcGKD0e0pMAhFJnS8zcXnVRb p2SEDfmEdyvU2nR6D/zrV166BQEIABsZ/hJwZ589UUFlShdqHlqzx8SptdMhFz2h uCOXAb2eTP9ZGgKOyQ7AOV4IoxdRneWIl3G2emrnh+8hTFy+Lg5MqOVPeqqqcJTs b2/TCS/6dC8= =Lew7 -----END PGP SIGNATURE-----