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?

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.

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

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

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