Subject Re: [IBO] IBO 4.2Ib violation of Fk...
Author Helen Borrie
At 03:06 PM 12/03/2003 -0300, you wrote:
>Delphi 6 SP2, IBO 4.2Ib, FB 1.0.821... ( have a portion of a DataModule... )
>This is a little problem with no soluction...
>We use IBO in our systems and we like a lot! But we are nervous with a
>trouble ( FK violation in Inserts )

FK violations occur when you try to write a value to the foreign key
column, that does not exist in the master table's primary key. It is
fairly common for such FK violations to occur where the PK and the FK are
of a non-precise data type, or include columns of non-precise data
type. Float, double precision and timestamp are non-precise.

>Maybe this problem is from any config, because of this we put a portion of
>components in this mail, if any user, know this trouble, maybe can help us.

Since this appears to be a metadata or casting problem, we need to see the
metadata of the tables which your queries access.

>We have a query with inner join and sub-select and not much parameters...
>and this works fine.
>Testing our program, try insert anything and works fine.. Close the insert
>window, try another thing, and try a second time this insert and....
>Violation of FK...
>We are curious, we list all fields in memory and it´s all fine, all correct!
>And if we delete the FK, this function write trash in Database....

You run the risk of trashing your database if you attempt to remove
constraints whilst active transactions are using the affected
objects. Always perform metadata changes on a shut-down database with
Owner having exclusive access.

Your comments are not meaningful. If you want us to help you, you need to
show us the code of your function, the affected metadata and snippets to
show us how the values are being passed to the parameters.

>Example from other table with the same trouble!
>Código: 0
>nome: "FROM CA_LPT || WHERE COD ...."
>valor: 20934532761459.2342

This does not mean anything. The snippet "FROM CA_LPT || WHERE COD ...."
is not part of a valid SQL statement.

>Maybe, the component are lose the true data and write a portion of other
>select... Worse, try to read this record do a Convert Error ... it´s not a
>valid integer!

Those are Delphi errors. 20934532761459.2342 is not an integer. You must
be trying to cast a string such as '20934532761459.2342' to integer, or
using the .Value method to cast a variant with an Extended format into an
Integer field.

>PS: We try to create a view with this select but this soluctions create
>others bigger troubles, and try to rewrite Select using only inner join´s,
>and the problem persist!.

This clue also suggests that you are using the wrong data types for
keys. But nobody can help until you provide appropriate information about
what you are doing to cause these problems.

Show us, for example, the code where you assign values to parameters.

Comments on your DFM excerpt:
It does not provide any information about any SQL that is passing foreign
key values.
I am also suspicious of your EditSQL. You should not be allowing users to
have update access to primary key columns.