I'm trying to semi-automate updating a non-live DBISAMQuery.

I'm thinking of looping through all fields checking if they belong to a
particular table and have been modified, and then putting together an SQL
script to be used by the DBISAMUpdateSQL component, in the onBeforePost
event.

I wondered what was the best way to identify the Primary key and use that
in the WHERE clause with the OLD_<Values>, or can I somehow access
RecordID?

Thanks for your pointers.

--
Chris

Chris,

<< I'm trying to semi-automate updating a non-live DBISAMQuery.

I'm thinking of looping through all fields checking if they belong to a
particular table and have been modified, and then putting together an SQL
script to be used by the DBISAMUpdateSQL component, in the onBeforePost
event.

I wondered what was the best way to identify the Primary key and use that
in the WHERE clause with the OLD_<Values>, or can I somehow access RecordID?
>>

You can use a TDBISAMTable to identify the primary key via its IndexDefs
property (ixPrimary flag in the TDBISAMIndexDef.Options property):

http://www.elevatesoft.com/dbisam4d5_tdbisamindexdefs.htm
http://www.elevatesoft.com/dbisam4d5_tdbisamindexdef.htm

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks a lot, Tim. I knew there had to be a simple way, but I couldn't spot
it.

Off to the circus now, with my (27 year-old) daughter - I'll look at this
tomorrow!

> You can use a TDBISAMTable to identify the primary key via its
> IndexDefs property (ixPrimary flag in the TDBISAMIndexDef.Options
> property):
>
> http://www.elevatesoft.com/dbisam4d5_tdbisamindexdefs.htm
> http://www.elevatesoft.com/dbisam4d5_tdbisamindexdef.htm
>



--
Chris

Tim,

 This works fine, and I now have an updatable multi-outer-joined query in
several inherited forms, where all I have to do is name the table I want to
update - just great!

Unfortunately it needs to open the named table to get the information about
the primary key. Is there no way to get this info directly from the mata-
data, as one or two of these tables are pretty big, and opening takes
several seconds.

Thinking out load, perhaps I should just put a filter on the table like
"TRUE = FALSE" or something?

--
Chris

> Unfortunately it needs to open the named table to get the information
> about the primary key.

Forget it, I've just discovered

aTable.IndexDefs.Update

- works just fine without needing to open the table.

--
Chris

Chris,

<< Forget it, I've just discovered

aTable.IndexDefs.Update

- works just fine without needing to open the table. >>

Actually, it does open the table to get this information.  I'm not sure
what's going on with your normal Open calls, but I would suspect that you've
got some un-optimized lookup field or calculated field issues if it's taking
several seconds to open the table.  Table open times shouldn't change
regardless of the size of the table.

--
Tim Young
Elevate Software
www.elevatesoft.com