> Hmmm. This seems like some kind of weird game. The thread you referred
> to, where you said your problem with DMLCaching was described, appears to
> be about something entirely different, i.e. how to make the demo apps work
> in the C++ Builder IDE. I see that I responded to that; and Lester
> posted
> some modified source to solve that problem, I understand.

Correct, however, the demo will not allow me to view the forms, so I am
unable to view the setup of the query(s), etc. So I am having to read the
DFM files, which is fine, but it complicates things as you can imagine, so I
may have miss something which could be the cause of my problem.

> Today you have posted a demo app including an executable that won't run
> anywhere except on your machine, because it uses your runtime libraries
> and
> is compiled with hard paths to locations on your computer.

Correct, I should have checked the settings. My apologies.

> I see in the DFM that you still have PessimisticLocking set true, even
> though Lester explained at some point that PL and DMLCaching couldn't be
> used together (unless one understands well how triggers work and is very
> careful about writing them to avoid firing them when you put your datasets
> into a writeable state!!) You can read up the TI sheet on DMLCaching to
> work out why PL would interfere with the triggers that DMLCaching uses.

I will have to read through the documentation once more, as I honestly can
not remember. But from your reply above (please correct me if I am wrong),
"Before type" triggers are a not compatible with PessimisticLocking ?

The simplified 'Survey Demo' DML_CACHE demo I wrote does not use "Before
type" triggers on the main table, they are all "After type" triggers.

The only "Before type" trigger is used on the DML_CACHE table, which is only
called once an Insertion, Update or Deletion has taken place. Thus,
notifying the other forms, etc via a "Event"

> Another thing I see in the DFM is that you have hard-coded at least two
> totally different DatabaseName properties in your test app. In IBO you
> should avoid that property and use TIB_Connection's Server, Path and
> Protocol properties; and, for transactions and statement objects, link
> them to the IB_Connection via the IB_Connection property.

Correction made, thanks.

> And NOWHERE do I find a description of any problem relating to DMLCaching,
> though I'm sure that the settings in your test app WOULD mess up
> DMLCaching.

As I mention to Lester, the Demo I wrote (Which follows the Survey Demo to
the letter), work perfectly. There is only one scenario in which it does not
behave as I would like.

I would like to stop multiple users from editing the same record at the same
point in time, but allow multi-read of the same record. Therefore, my
understanding is that I have to set the PessimisticLocking property = true
on the IB_Query.

But if I do this, and try to edit a single record (and no other instance of
the application or form is currently editing the record in question) I get
the following error:

> ISC ERROR CODE: 335544569
> ISC ERROR MESSAGE:
> Dynamic SQL ERROR
> SQL error code =-510
> Cursor not updatable.

So my original question was what have I done incorrectly?

Lester replied with:

> Don't use PessimisticLocking myself. If I need to lock records, a 'last
> modified' field gets updated, and that tells other users that the
> record is 'busy' and who it is busy with ( -ve user_id = editing, +ve
> user_id = last > changed by )

Which from what I understand, he programmatically checks the content of the
'last_modified' field prior to allowing the record to be edited.

I was hopping that by following the sample "Survey Demo" as well as adding
the PessimiticLocking = true I could achieve the same thing. But it appears
that I am wrong or that my understanding and subsequent implementation is
wrong.

> So - if that's all the info available, then I doubt there's anything Jason
> or I could do with it. How about describing *the problem* ? I'm happy to
> try and help, as long as you can put a frame around what you need....
>
> Helen

If need be I can update the posted file without the previous errors(hardwire
paths etc).

Thanks

Daniel