>Their intent is to prevent as much as possible the compatibility confusion
>that'd arise from several apps reading or writing the old format, since the
>current ("old") format will be shortlived. They don't want to restrict
>folks, but just don't want to support two formats and deal with all the
>issues that causes. (Sure, it would have been nice if the initial format
>had been what they wanted to stick with, but I can't change the past, much
>as I try.)
>
>I will forward along your note as a reminder that people are still quite
>interested, and perhaps they'll reconsider the decision. Regardless,
>this'll help them when they go through the process next time a data format
>gets created.
If, perchance, the existing records contain a 'version' field (they may or
may not, I can only hope!), we could happily code in such a way that we
could currently warn if the version is 'too new' (ie, if version > 1) and
in the future also be able to handle records of various formats by checking
the version field. Overhead would be (would have been?) 1 byte per record
(or per database if you were willing to restrict a DB to containing records
all of the same version and store it in the info block), but would save us
this exact problem.
Brian
_____________________________________________________________________
Mark/Space Softworks voice 408-293-7299
111 West Saint John, 3rd Floor fax 408-293-7298
San Jose, CA 95113 <http://www.markspace.com>
PalmOS, Mac OS, Windows and Web Software & Solutions:
PageNOW! Wireless Messaging, PhoneWatcher Caller ID,
Fax Send and Receive for PalmOS
Online & Communicate terminal emulation and serial debugging
DataCord serial data cables for Handheld Devices
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
