How determine PDB changed?

[handbase@avisys.net]

How does the desktop determine if, after a sync, the new PDB in My Documents . . . is different from the one originally there, i.e., has been updated?

What I'm getting at is can I programatically do the same, such as store a list of whatever the checksums or semaphores might be and then compare after sync?

Thanks,

Jerry

[Brian_Houghton]

HanDBase opens the two databases being synced and compares an internal value that is associated with each record in order to determine if the record has changed since the last sync.

This information is not accessible to anyone at this time.

Sent from my Nexus 7 using Tapatalk HD

[handbase@avisys.net]

Uuuuh! Thanks.

Is it possible that "not accessible" could change?

Of course it's "accessible" --- we just don't know what and where it is.<G> Is it a "dirty bit?" or a "dirty byte?"

Well I guess I can understand. To describe it would be, in a way, describing the file format . . .

Thanks,

Jerry

[dhaupert]

First you'd have to be able to parse the records- the header of each record contains a few flags, a unique ID, and a time stamp of when it was modified. When syncing, the conduit compares the time stamps. A dirty bit only works if you're syncing between two devices, but HanDBase can sync between any number of copies, so that's why we no longer use a dirty bit like the old Palm PDB files did.

To parse out the records, you'd have to read the header of the PDB file which contains a binary list of all offsets within the file to find the beginning of each record. Then you have to calculate the math between the offsets of two records, to determine the size of the record. Then you'd have to decode the binary header and flags.

All of this is proprietary as we are not an open format, so that's why we present the tools to convert to a format that you can use like the CSV format. We optionally can export the time stamps so you can manually do your comparisons and merges without dealing with the binary and proprietary file format, and then convert back when finished. I think that's the best route for you at this time.

I've always been open to the idea of the file format not being proprietary but honestly there has been little interest in this in many years so it doesn't pay to document the file format at this time.

[handbase@avisys.net]

//// We optionally can export the time stamps so you can manually do your comparisons and merges

Is that something I missed in the desktop docs, or do I misunderstand?

And doesn't the timestamp change on every sync, regardless whether the database is dirty? Or are you talking about another kind of timestamp?

Parsing the file seems pretty straightforward, as you describe it --- although nothing is as simple as it seems.<G> In my case, at least, once the code is written it becomes a simple function --- all my customers' records will be of identical format. (Assume iOS looks like Android??)

Major distractions have interfered with my development process, but things are now rolling again. I have my application finding all (up to 12) user devices, mixed iOS and Android, and listing them for selection, creating databases (all are identical except for content), replicating databases, installing databases from CSV, deleting databases, displaying installed databases for each device. For the last, I really need to be able to mark those that are dirty --- the reason I ask. I'd hate to leave it to my customers to remember which ones they updated. There's gotta be a way without my hacking the database format --- I don't have that much time.<G>

Thanks,

Jerry

[dhaupert]

Hi Jerry,

Sounds like you've accomplished a lot! The time stamp is a header storage item, not a field within the record. We store it for every single record, including the popup lists, the database header record, etc. They are not always in the same place in the file. These are part of a 24 byte leading header at the beginning of each record as stored in the database. If you convert to CSV using the windows desktop you'll see options to convert the GUID fields and those are the ones that are representations of the header in a text form. Not readable by humans, but means something to HanDBase!