script update of DB linked field fails to update

[strongbow]

Hi all

Using v3 with SQLite DB and thought I'd try again using the QueryObjects. So have a bunch of fields which are linked to DB and set to update on edit. One of these fields is updated under script control but does not get updated in the DB. Any ideas why?

I'd prefer to fix these types of problems (if possible) than to continue to use workarounds (i.e. putting an "Update" button, etc).

On a related note, saving binary objects (e.g. pictures) should also be better handled. For example, I've read that it's best to base64encode/decode BLOBs before saving in the DB. But this assumes that a picture has been imported into an image object, rather than as a reference (using "set the filename .."). Surely in our DB library it would be easy to check for this and change the settings if necessary?

i.e. if the filename of an image object is set then read the image in, encode if necessary, before saving. And the reverse when reading?

Anyone have more info / comments?

cheers

Alan

[Janschenkel]

I'd file an enhancement request for the 'referenced' images.

As for updating fields under script control, all you have to do is let the revDatabase frontscript know that you changed it. Here's an untested idea:

Code: Select all

on mouseUp
  put "foo" into field "bar"
  -- field "bar" is database-linked so we need to trigger an update
  try
    send "closeField" to field "bar"
  catch tError
    -- ignore
  end try
end mouseUp

The 'try-catch' block is needed to avoid errors if there's no generic 'closeField' handler in the message path.

Hope this helped,

Jan Schenkel.

[strongbow]

Hi Jan

Thanks for the reply, yes, sending the closeField will work. I sort of didn't want to do that, but realise now, after looking more at the revDatabase scripts, that this is fine. Re-looking at the scripts also gave me a solution for the DB linked Image problem.

To ensure an image is updated, even if it is set using "set the filename of ..." you can use:

revWriteImageData the long id of me, tTargetFile

which is the revDatabase script that updates the DB for an image object.

where "the long id of me" is the long id of the image object containing the target image
and tTargetFile is the path and filename of the original image that has been referenced.

This seems to work fine as a binary too, not needing the base64 en/decoding as previously described.

Having said all that, I've only *just* tried it now, so further testing may reveal more. Hopefully it's all go!

Thanks for taking the time to reply, and so quickly!!

cheers

Alan