Subject | Re: [IBO] IBO 4.2Ib violation of Fk... |
---|---|
Author | Helen Borrie |
Post date | 2003-03-13T05:45:57Z |
At 03:06 PM 12/03/2003 -0300, you wrote:
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.
metadata of the tables which your queries access.
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.
is not part of a valid SQL statement.
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.
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.
Helen
>Delphi 6 SP2, IBO 4.2Ib, FB 1.0.821... ( have a portion of a DataModule... )FK violations occur when you try to write a value to the foreign key
>
>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 )
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 ofSince this appears to be a metadata or casting problem, we need to see the
>components in this mail, if any user, know this trouble, maybe can help us.
metadata of the tables which your queries access.
>We have a query with inner join and sub-select and not much parameters...You run the risk of trashing your database if you attempt to remove
>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....
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!This does not mean anything. The snippet "FROM CA_LPT || WHERE COD ...."
>
>Código: 0
>nome: "FROM CA_LPT || WHERE COD ...."
>valor: 20934532761459.2342
is not part of a valid SQL statement.
>Maybe, the component are lose the true data and write a portion of otherThose are Delphi errors. 20934532761459.2342 is not an integer. You must
>select... Worse, try to read this record do a Convert Error ... it´s not a
>valid integer!
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 createThis clue also suggests that you are using the wrong data types for
>others bigger troubles, and try to rewrite Select using only inner join´s,
>and the problem persist!.
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.
Helen