Hi

I get error code 1305 when loading updates from table [A] into table [B]. They are identical tables except the seed for the Primary Key which is an
Autoinc filed is different. Table [A] has a seed of 2000001 and table [B] has a seed of 1200000000.

The message is as follows: An error occured in the statement at line 24 and column 39 (Error loading the updates for the database FDD04 (No row found
in the table FDA2A with the primary key values of 2000002)).

When I removed the generated flag on the primary key of table [B] and make it just a normal Integer field (not AutoInc), the update worked with no
errors.

Could you please advise me on this issue...

Kind Regards

Alfred

Alfred,

<< The message is as follows: An error occured in the statement at line 24
and column 39 (Error loading the updates for the database FDD04 (No row
found in the table FDA2A with the primary key values of 2000002)). >>

That indicates that one of the updates being loaded is an update or delete,
and that EDB can't find the row with that primary key in the table.  Does
that row actually exist in the target FDA2A table ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

<<That indicates that one of the updates being loaded is an update or delete,
and that EDB can't find the row with that primary key in the table.  Does
that row actually exist in the target FDA2A table ?>>

No the row did not exist. But somehow I felt it had to do with the autoinc setting of the filed or its seeding value.

So, I fixed the issue by changing all primary keys (which are auto generated - autoinc type) from "generated always" to "generated by
default", and all updates worked.

Does this make sense? if it does, could you kindly help me understand what happened.

It would be great to have a whitepaper on how replication works in detail...

Thanks for your help and kind regards...

Alfred

Alfred,

<< No the row did not exist. But somehow I felt it had to do with the
autoinc setting of the filed or its seeding value.

So, I fixed the issue by changing all primary keys (which are auto
generated - autoinc type) from "generated always" to "generated by default",
and all updates worked.

Does this make sense? >>

No, it doesn't.  The error message that you received was for an update, not
an insert, and IDENTITY columns are only set during an INSERT.  I'm very
positive that this is the case, so something weird is going on or I'm really
missing something important.

Could you possibly send me the database catalog and table files of the
target database, along with the update file that you're trying to load ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

HI Tim

Thanks for your help...

Sorry I couldn't send the files you requested as I deleted the whole setup and moved quickly to sort the application for the client.

I have a long list of issues that I encountered and ideas which I would like to send them to you for consideration (That is, IF I find them and
put them together. My notes are scattered everwhere .

Anyway, while I was tidying the applications, I wished if you could kindly clarify this for me:

I have database A replicating with database B, in both directions. Is it right that if I modified table A1 in database A and not table B1 in
database B, will cause the replication to fail?

If the modification was not in the fields but just adding a trigger or modifying an existing trigger of table A1 but not to table B1? Will this cause
replication failure?

Kind Regards

Alfred

Alfred,

<< Sorry I couldn't send the files you requested as I deleted the whole
setup and moved quickly to sort the application for the client. >>

No problem.  Getting the client sorted out is first and foremost.

<< I have a long list of issues that I encountered and ideas which I would
like to send them to you for consideration (That is, IF I find them and put
them together. My notes are scattered everwhere .  >>

Sure, send over whatever you've got.

<< I have database A replicating with database B, in both directions. Is it
right that if I modified table A1 in database A and not table B1 in database
B, will cause the replication to fail? >>

If you're talking about modifying the structure of the table, then yes, if
you add or remove a column in one table but not the other, then yes, this
could cause the replication to fail with a "column not found error".  I
thinking about adding an option to ignore missing columns, however.

<< If the modification was not in the fields but just adding a trigger or
modifying an existing trigger of table A1 but not to table B1? Will this
cause replication failure? >>

No, that will not.  The only requirement is that the primary keys match, and
that the columns match.

--
Tim Young
Elevate Software
www.elevatesoft.com