[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] Problems with dlp_req.Don't know what do Ireceive.



On Fri, 15 Jun 2001, Wojtek wrote:
> my ($err,@ret)=&dlp_req(0x1f,{id=>0x20,data=>pack("C",$dbh)});
>
> Does @ret contain raw data of record ?

	First of all, I would recommend not using
	&dlp_req(0xNN, ...
in your code. Instead, write a wrapper function
&ColdSync::SPC::dlp_ReadNextModifiedRecord, and send me the patch.

	$ret[0]->{data} contains the raw data of the DLP argument returned
from the Palm. This includes the record ID, index, size, attributes,
category, and data. You need to unpack this before doing anything
meaningful with this record.

> Why I get message : record NN has same offset as previous one: NNNN   ?

	I don't know. This happens when there's a record of length zero in
your PDB. I don't know why this is happening to you, though.

> Algorithm of my sync conduit:
> 1.get dbinfo (spc_getdbinfo)
> 2. open db    (dlp_OpenDB)
> 3 read next modified record   ($err,@ret)=dlp_req(0x1f,)
> 4. append new record to pdb
> 5.  $record->{data}=@ret[0]->data   (of course if @ret[0]->{id}==0x20 )
> 6 close db
> 7 write pdb

	Assuming that you want to create a .pdb file containing all of the
modified records from the Palm, this sounds reasonable. However, as I
mentioned above, the data returned by &dlp_req is very raw, and probably
needs to be parsed by a helper class before it can be meaningfully added
to a PDB.
	For example, if $PDB is a Palm::Address, it expects its records to
be of the form

	$record = {
		name => "Arensburger",
		firstname => "Andrew",
		...
	};

If you use
	$PDB->append_record({ data => "Arensburger\0Andrew\0..." });
then when you $PDB->Write() the file, it'll see that $record->{name} is
undefined, $record->{firstname} is undefined, etc. and won't even look at
$record->{data}.

	If your script is supposed to work with all database types, you
should probably use Palm::Raw.

	Lastly, in your algorithm above, you're not resetting the sync
flags at the end. This means that if record 0x12345678 is marked "dirty"
when you run this script, it'll still be marked dirty when the script
terminates.
	I don't know if this is intentional or not. If you run the generic
conduit after your script, then the generic conduit will reset the sync
flags. However, if you reset the sync flags and then run the generic
conduit, then the generic conduit won't run correctly, because it uses the
sync flags to find out which records have been modified since the last
sync.

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01

This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.