Try :
if Locate('Cedula',TIB_Edit.Text,[loCaseInsensitive]) then



[]´s

----- Original Message -----
From: rudi_josic
To: IBObjects@yahoogroups.com
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 IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> "Catch-22" - Locate() searches the dataset buffer. Since you have
already
> inserted this data, it is already in the buffer and so will always
return
> 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
handling.

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
will
> throw a dataset exception if you try to insert a key value that it
already
> "knows" about. You catch this exception and return control to the
user.
>
> 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
client's
> 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
this
> 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
Violation
> 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_
controls
> to determine the value in the buffer. Read the underlying Fields[]
value
> (or FieldByName, or Row.ByName) of the dataset, and cast it to type
using
> 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.
___________________________________________________________________________
http://www.ibobjects.com - 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]