![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Sat, Jul 25 2009 2:22 AM | Permanent Link |
Jeff Dunlop | Hi -- when I replicate a particular table that has a VARCHAR(3) field with a value of
'001', the value replicates to the remote database as '1'. I'm on v2b10. Can anyone shed any light on why this is happening? |
Sat, Jul 25 2009 7:27 PM | Permanent Link |
Jeff Dunlop | There was an insert trigger copying values to another table. The destination field was
improperly an integer instead of a varchar(3). It appears that Elevate retained a remnant of the outbound conversion and wrote an incorrect value into the table. Subtle, but I believe it is a defect. |
Mon, Jul 27 2009 4:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Jeff,
<< There was an insert trigger copying values to another table. The destination field was improperly an integer instead of a varchar(3). It appears that Elevate retained a remnant of the outbound conversion and wrote an incorrect value into the table. Subtle, but I believe it is a defect. >> EDB will not allow you to load an update's column value into a column that has a different major type (major being INTEGER vs. VARCHAR as opposed to VARCHAR vs. CHAR). Perhaps you could explain the situation in more detail and I could tell you whether the situation is normal or not. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jul 28 2009 10:09 PM | Permanent Link |
Jeff Dunlop | No, I got the schema wrong in the destination table and only noticed it when
troubleshooting the behavior. I think throwing an exception would be a better implementation of "Not allow" than silently modifying the source field. "Tim Young [Elevate Software]" wrote: Jeff, << There was an insert trigger copying values to another table. The destination field was improperly an integer instead of a varchar(3). It appears that Elevate retained a remnant of the outbound conversion and wrote an incorrect value into the table. Subtle, but I believe it is a defect. >> EDB will not allow you to load an update's column value into a column that has a different major type (major being INTEGER vs. VARCHAR as opposed to VARCHAR vs. CHAR). Perhaps you could explain the situation in more detail and I could tell you whether the situation is normal or not. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jul 29 2009 12:20 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Jeff,
<< No, >> What specifically are you responding to here ? << I got the schema wrong in the destination table and only noticed it when troubleshooting the behavior. I think throwing an exception would be a better implementation of "Not allow" than silently modifying the source field. >> As I indicated already, EDB will not modify or change anything about the source data, and keeps the source data type with the source data through the entire process, raising an exception if you try and load one column type into a differently-typed column. So, I'm still don't really understand the situation that you're describing, and what the trigger has to do with it. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |