Re: Foriegn key checking.

Mark,

I think you ought to have used the RTRIM function since it is a char column.

Cecil

Mark Parssey wrote in message
<01bcd79b$fc2de460$ad0b6d93_at_l8ip173.delm.tas.gov.au>...
>I have a table which is driving me around the twist.
>
>It is being used as a foreign key and is stopping the app. by failing to
>query successfully.
>
>The table holds only a few values, the key field is char 3 & currently has
>the values 3.1, 3.2, 4 & 5.
>
>A query for all values or for 3.1 or 3.2 is OK but when I do a simple query
>on that table using the 4 or 5 it fails.
>It does work Ok for 4% but also fails for 4 'space' 'space' or 'space'
>'space' 4.
>
>This same behaviour is causing the entry screen which attempts to use these
>values (4 or 5) as foreign keys to reject any attempt to use them.
>
>Can someone tell me what is going on?
>
>I don't really want to have to change the field to numeric as the fields
>relate to sections of a parlimentary act and could jsut as likely refer to
>6A or similiar in the future.
>
>And just to top it off.
>Having got frustrated with the foreign key prob on the entry screen I did
>an alter table drop constraint.
>All seems fine. SQLPlus said table altered , there is no entry in
>user-contraints that would indicate that the Fkey constraint still exists.
>But the screen still gives Fkey errors, even after killing the session &
>connecting again.
>
>Is this logic being implemented on the client side somehow & do I need to
>make changes to the form?
>
Received on Mon Oct 13 1997 - 00:00:00 CDT