Subject Re: [IBO] Re: using Tib_Query.Locate in inserting mode
Author Suporte - OnClick
Try :
if Locate('Cedula',TIB_Edit.Text,[loCaseInsensitive]) then


----- Original Message -----
From: rudi_josic
Sent: Monday, September 27, 2004 10:32 PM
Subject: [IBO] Re: using Tib_Query.Locate in inserting mode

Thanks Helen.

I'll try another solution and explain to my teacher why.

--- In, Helen Borrie <helebor@t...> wrote:
> "Catch-22" - Locate() searches the dataset buffer. Since you have
> inserted this data, it is already in the buffer and so will always
> true !
> It's not your fault. Your teacher is unfortunately showing his/her
> ignorance of multi-user systems if he/she has told you to use Locate
() for
> this test. The proper way to handle this is through exception

Ok, i'd do it (exception handling) and it works fine (catch the
exception, show a message and focus the control that cause the
problem), but my teacher told me that he want to receive the message
when leave the edit control, not when try to 'Save' the new record.

(i'm free to decide the tools and methods to do the job, he only
check the results, he never saw the source code and never will see
it. just the .exe)

So i'll try another way to do it.

> Provided you have set up KeyLinks properly, your client "knows"
about keys
> that are in its KeyFields buffer. In there, it will have the keys
for a)
> the records that were visible to the transaction when it began and
b) any
> uncommitted records that the user has inserted. In BeforePost, IBO
> throw a dataset exception if you try to insert a key value that it
> "knows" about. You catch this exception and return control to the
> However, there are other records that the dataset does not "know"
> about. Those are records (changed or inserted by another client)
that were
> committed after your client's transaction began. Even if your
> transaction is in ReadCommitted isolation, your client's dataset
does not
> know about these changes until it tries to post its own changes.
> The essential thing that your teacher has overlooked when setting
> requirement is this: even if the dataset permits the insert, it
may still
> be rejected on Post by the server because of activity by other
> transactions. Thus, you must also catch and handle the Key
> exception returned by the server when the Post is attempted.

There is not a problem, i'd implement a DML Caching based on Survey
example from IBO Tech Info Sheets, so the datasets is always updated,
i guess ;)

> Note, also, that you should not read the Text property of the IB_
> to determine the value in the buffer. Read the underlying Fields[]
> (or FieldByName, or Row.ByName) of the dataset, and cast it to type
> the appropriate "AsWhatever" casting method.

Ok, i'll change it.

> Helen

Thanks again Helen.

Rudi Josic.

IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________ - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Yahoo! Groups Links

[Non-text portions of this message have been removed]