Version :
remote ASA 8.0.3.5191
consolidate : ASE 12.5.1 EBF 11665 ESD#2

The problem occurs during the first synchronization with the remote
database.
All the lines in the ArtImage table have been just inserted.
all the tables are synchronized according to the same principle
(forced-conflicts) with any problem only the table with a column of the blob
type poses problem.

Script upload_new_row_insert is called twice.
The first time with a null value for the column artimage.
The second time with the good value for artimage :

E. 10/03 10:37:23. <1.5> [derognat] : Erreur: ODBC : [DataDirect][ODBC
Sybase Wire Protocol driver][SQL Server]Attempt to insert duplicate key row
in object '#artimage_new00000530011296757' with unique index
'#artimage_new_pk'
(Etat ODBC = 23000, Code d'erreur natif = 2601)

in this case, script upload_old_row is also called (illogical, there are
only new values)

log :
I. 10/03 10:35:39. <1.5> [derognat] : begin_upload_rows ArtImage
CREATE TABLE #artimage_old
(
artcode int not null,
artimage image null,
artnomimage varchar(256) null,
fouid varchar(9) not null,
constraint #artimage_old_pk primary key(artcode,fouid)
)
I. 10/03 10:35:39. <1.5> [derognat] : SQL converti :
CREATE TABLE #artimage_old
(
artcode int not null,
artimage image null,
artnomimage varchar(256) null,
fouid varchar(9) not null,
constraint #artimage_old_pk primary key(artcode,fouid)
)
I. 10/03 10:35:39. <1.5> [derognat] : SQL converti :
save tran it12
I. 10/03 10:35:39. <1.5> [derognat] : Toutes les lignes de téléchargement
insérées de la table 'ArtImage' seront traitées comme générant un conflit :
aucun script upload_insert n'est défini pour cette table.
I. 10/03 10:35:39. <1.5> [derognat] : Ligne insérée :
I. 10/03 10:35:39. <1.5> [derognat] : 1439
I. 10/03 10:35:39. <1.5> [derognat] : [85937 octets]
I. 10/03 10:35:39. <1.5> [derognat] : CRAY201812.JPG
I. 10/03 10:35:39. <1.5> [derognat] : upload_new_row_insert ArtImage (ouvert
en écriture) :
declare @fouid varchar(9)
execute ml_user_getfouid @fouid out
insert into
#artimage_new(artcode,artimage,artnomimage,fouid) values(?,?,?,@fouid)
I. 10/03 10:35:39. <1.5> [derognat] : SQL converti :
declare @fouid varchar(9)
execute ml_user_getfouid @fouid out
insert into
#artimage_new(artcode,artimage,artnomimage,fouid) values(?,?,?,@fouid)
I. 10/03 10:35:39. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)
I. 10/03 10:35:39. <1.5> [derognat] : Ligne insérée :
I. 10/03 10:35:39. <1.5> [derognat] : 3918
I. 10/03 10:35:39. <1.5> [derognat] : [99100 octets]
I. 10/03 10:35:39. <1.5> [derognat] : PEIN247245.JPG
I. 10/03 10:35:39. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)
I. 10/03 10:35:39. <1.5> [derognat] : Ligne insérée :
I. 10/03 10:35:39. <1.5> [derognat] : 3919
I. 10/03 10:35:39. <1.5> [derognat] : [97455 octets]
I. 10/03 10:35:39. <1.5> [derognat] : PEIN247250.JPG
I. 10/03 10:35:40. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)
I. 10/03 10:35:40. <1.5> [derognat] : Ligne insérée :
I. 10/03 10:35:40. <1.5> [derognat] : 3923
I. 10/03 10:35:40. <1.5> [derognat] : [99750 octets]
I. 10/03 10:35:40. <1.5> [derognat] : PEIN247315.JPG
I. 10/03 10:35:40. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)

.......

I. 10/03 10:37:22. <1.5> [derognat] : Ligne insérée :
I. 10/03 10:37:22. <1.5> [derognat] : 2623
=> I. 10/03 10:37:22. <1.5> [derognat] : NULL
I. 10/03 10:37:22. <1.5> [derognat] : GRAN015012.JPG
I. 10/03 10:37:22. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)
I. 10/03 10:37:22. <1.5> [derognat] : La ligne sera traitée comme générant
un conflit car la ligne consolidée n'existe plus.
I. 10/03 10:37:22. <1.5> [derognat] : Mise à jour de la ligne (nouvelles
valeurs distantes)
I. 10/03 10:37:22. <1.5> [derognat] : 2623
=> I. 10/03 10:37:22. <1.5> [derognat] : [92562 octets]
I. 10/03 10:37:22. <1.5> [derognat] : GRAN015012.JPG
E. 10/03 10:37:23. <1.5> [derognat] : Erreur: ODBC : [DataDirect][ODBC
Sybase Wire Protocol driver][SQL Server]Attempt to insert duplicate key row
in object '#artimage_new00000530011296757' with unique index
'#artimage_new_pk'
(Etat ODBC = 23000, Code d'erreur natif = 2601)
E. 10/03 10:37:23. <1.5> [derognat] : Erreur: Impossible d'effectuer des
insertions dans la table "ArtImage" à l'aide de upload_new_row_insert
I. 10/03 10:37:23. <1.5> [derognat] : Contexte de l'erreur :
nom_utilisateur : derognat
nom_utilisateur_modifié : 21007879
Transaction : upload
nom_table : ArtImage
I. 10/03 10:37:23. <1.5> [derognat] : Ligne :
I. 10/03 10:37:23. <1.5> [derognat] : 2623
I. 10/03 10:37:23. <1.5> [derognat] : [92562 octets]
I. 10/03 10:37:23. <1.5> [derognat] : GRAN015012.JPG
I. 10/03 10:37:23. <1.5> [derognat] : Version du script : version_139
Script : declare @fouid varchar(9)

execute ml_user_getfouid @fouid out

insert into
#artimage_new(artcode,artimage,artnomimage,fouid) values(?,?,?,@fouid)
Fin du contexte de l'erreur
W. 10/03 10:37:23. <1.5> [derognat] : Avertissement: [10010] Le script
handle_error n'est pas défini. Le code d'action par défaut (3000) va définir
le comportement de l'erreur.
I. 10/03 10:37:23. <1.5> [derognat] : Mise à jour de la ligne (anciennes
valeurs distantes)
I. 10/03 10:37:23. <1.5> [derognat] : 2623
I. 10/03 10:37:23. <1.5> [derognat] : NULL
I. 10/03 10:37:23. <1.5> [derognat] : GRAN015012.JPG
I. 10/03 10:37:23. <1.5> [derognat] : upload_old_row_insert ArtImage (ouvert
en écriture) :
declare @fouid varchar(9)
execute ml_user_getfouid @fouid out
insert into
#artimage_old(artcode,artimage,artnomimage,fouid) values(?,?,?,@fouid)
I. 10/03 10:37:23. <1.5> [derognat] : SQL converti :
declare @fouid varchar(9)

execute ml_user_getfouid @fouid out

insert into
#artimage_old(artcode,artimage,artnomimage,fouid) values(?,?,?,@fouid)
I. 10/03 10:37:23. <1.5> [derognat] : resolve_conflict ArtImage (aucun
script)
I. 10/03 10:37:23. <1.5> [derognat] : Une erreur s'est produite lors du
téléchargement d'une ligne mise à jour dans la table 'ArtImage'. Les valeurs
de colonne mises à jour sont les suivantes :
I. 10/03 10:37:23. <1.5> [derognat] : 2623
I. 10/03 10:37:23. <1.5> [derognat] : [92562 octets]
I. 10/03 10:37:23. <1.5> [derognat] : GRAN015012.JPG
I. 10/03 10:37:23. <1.5> [derognat] : upload_new_row_insert ArtImage
(fermer)
I. 10/03 10:37:23. <1.5> [derognat] : upload_old_row_insert ArtImage
(fermer)
I. 10/03 10:37:23. <1.5> [derognat] : 733 lignes traitées et jugées en
conflit dans la table ArtImage
I. 10/03 10:37:23. <1.5> [derognat] : SQL converti :
rollback tran it12
I. 10/03 10:37:50. <1.5> [derognat] : ANNULATION de la transaction :
end_upload

"Philippe Bucaille" <Philippe.Bucaille (AT) afinity-fr (DOT) com> wrote in
news:42316b86@forums-2-dub of sybase.public.sqlanywhere.mobilink:

PB> Version :
PB> remote ASA 8.0.3.5191
PB> consolidate : ASE 12.5.1 EBF 11665 ESD#2

And what actions had you performed on the remote?
Was it 1 insert, followed by a commit, the ran dbmlsync?
Or did you do multiple statements with various commits before running
dbmlsync.

Please be as specific as possible.

--
David Fishburn
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Professional Services
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).

EBFs and Maintenance Releases
http://downloads.sybase.com/swx/sdmain.stm

Developer Community / Whitepapers
http://www.ianywhere.com/developer

CaseXpress - to report bugs
http://casexpress.sybase.com

CodeXchange - Free samples
http://ianywhere.codexchange.sybase....ctDocumentList

It is the first synchronization of the remote database after reloading.
Consequently, there is not of multiple statements only one insertion.

I converted the remote transaction log to try to analyze his contents.
But the file size is more important to publish it (500 Mo).

The problem occurs with the 733 lines on roughly (1400). There is normally
no notable difference between the lines (formulation).
It does not have a problem with the other tables (even principle) .

Information : The tables are not reloaded by a procedure (dbunload). I
wrote a program in powerbuider which moves the data towards temporary tables
by holding account of the integrity constraints (dynamic pipeline). The
tables are emptied and reloaded starting from the temporary tables.
The operation lasts only a few minutes compared to operation
(unload/reload).

This procedure functions usually well, but we never used such a significant
volume of information.

"David Fishburn" <fishburn_spam (AT) off (DOT) ianywhere.com> a écrit dans le message
news: Xns9619A4C05AEC0fishburnsybasecom (AT) 127 (DOT) 0.0.1...