Discussion :

[gerald2545]

Bonjour,
je viens vers vous pour essayer de comprendre comment fonctionne la vérification de l'unicité dans postgresql (v 7.4.8) (et au final essayer de résoudre mon problème).

Pour simplifier, j'ai une table trace_object qui comporte 3 colonnes :
code_barre_id, SERIAL,PKEY
code_barre, varchar (15), UNIQUE
code_barre_crypte, varchar(15), UNIQUE

sachant que la colonne code_barre_crypte est dérivée de la colonne code_barre : code_barre_crypte = text2code128 (code_barre).
La fonction text2code128 est une fonction qui prend en entrée le code-barre lisible et renvoie en sortie le code-barre crypté.

Mon souci intervient pour 2 code-barres que je veux insérer dans ma table : AB28662097 et AB28662098. Les code-barres cryptés renvoyés par la fonction text2code128 sont respectivement ÌABÇ<b4ÅÃÎ et ÌABÇ<b4ÆÊÎ.
A priori, ils sont différents....mais pas pour postgesql qui me jette en me disant que la contrainte d'unicité de la colonne code_barre_crypte est violée ()

ERROR: duplicate key violates unique constraint "unique_barcode128"

La définition de l'index créé par postgresql est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE UNIQUE INDEX unique_barcode128 ON trace_object USING btree (code_barre_crypte)

Comment se fait-il que cette contrainte d'unicité soit violée alors que les données que je tente d'insérer sont différentes?
Si quelqu'un s'est déjà trouvé dans ce cas de figure....ou si vous avez des pistes...
merci d'avance.
Précisions : j'ai essayé de mon interface web, de phpPgAdmin, en ligne de commande, avec ou sans l'aide de la fonction text2code128 : l'erreur est toujours la même.
Autre précision : j'ai installé la routine text2code128 en tant que macro d'openoffice et j'ai imprimé les code-barres correspondant à AB28662097 et AB28662098. Je les ai scanné et ai bien retrouvé mes petits, cette fonction "fonctionne" donc à merveille.....

[GrandFather]

Bonjour,

quel est le code SQL qui te fait l'insertion dans la table ?
Ce ne sont que ces deux codes qui te posent problème ?

[gerald2545]

ces 2 code-barres font partie d'un lot de 260 qui devaient être insérés dans une transaction.
Quand je supprime 1 de ces 2 code-barres, les 259 autres de la liste s'insère en base sans erreur. Donc ça ne doit pas venir de ma requête d'insertion (d'autant que j'arrive à environ 1000 code-barres de ce type, i.e. ABxxxxxxxx, insérés en base sans problème avant cela).

I'm perplexe

exemeples des code-barres insérés :
AB28676949
AB28676950
AB28676952
AB28676953
AB28686772
AB28662097
AB28662098
AB28676940
AB28676941
AB28676942
AB28676945
AB28676946

[GrandFather]

Quel est l'encodage de ta base ? Si c'est SQL_ASCII, ça pourrait peut-être expliquer ce problème d'index...

[gerald2545]

En effet, je voulais le préciser dans mon premier post, l'encodage de ma base est en SQL_ASCII....
Alors là en terme d'encodage, je n'y connaîs rien....quel type d'encodage devrais-je utiliser pour éviter ce genre de problème?
Merci pour vos réflexions

PS : j'ai joint les variables postgresql liées à ma base....

Nom Paramétrage
add_missing_from on
australian_timezones off
authentication_timeout 60
check_function_bodies on
checkpoint_segments 128
checkpoint_timeout 300
checkpoint_warning 30
client_encoding SQL_ASCII
client_min_messages error
commit_delay 0
commit_siblings 5
cpu_index_tuple_cost 0.001
cpu_operator_cost 0.0025
cpu_tuple_cost 0.01
DateStyle ISO, MDY
db_user_namespace off
deadlock_timeout 1000
debug_pretty_print off
debug_print_parse off
debug_print_plan off
debug_print_rewritten off
default_statistics_target 10
default_transaction_isolation read committed
default_transaction_read_only off
dynamic_library_path $libdir
effective_cache_size 12500
enable_hashagg on
enable_hashjoin on
enable_indexscan on
enable_mergejoin on
enable_nestloop on
enable_seqscan on
enable_sort on
enable_tidscan on
explain_pretty_print on
extra_float_digits 0
from_collapse_limit 8
fsync on
geqo on
geqo_effort 1
geqo_generations 0
geqo_pool_size 0
geqo_selection_bias 2
geqo_threshold 11
join_collapse_limit 8
krb_server_keyfile FILE:/etc/sysconfig/pgsql/krb5.keytab
lc_collate en_US.utf8
lc_ctype en_US.utf8
lc_messages en_US
lc_monetary en_US
lc_numeric en_US
lc_time en_US
log_connections on
log_duration off
log_error_verbosity default
log_executor_stats off
log_hostname off
log_min_duration_statement -1
log_min_error_statement error
log_min_messages error
log_parser_stats off
log_pid off
log_planner_stats off
log_source_port off
log_statement off
log_statement_stats off
log_timestamp on
max_connections 100
max_expr_depth 10000
max_files_per_process 1000
max_fsm_pages 20000
max_fsm_relations 1000
max_locks_per_transaction 64
password_encryption on
port 5432
pre_auth_delay 0
preload_libraries unset
random_page_cost 4
regex_flavor advanced
rendezvous_name unset
search_path $user,public
server_encoding SQL_ASCII
server_version 7.4.8
shared_buffers 65536
silent_mode off
sort_mem 16000
sql_inheritance on
ssl off
statement_timeout 0
stats_block_level off
stats_command_string off
stats_reset_on_server_start on
stats_row_level off
stats_start_collector on
superuser_reserved_connections 2
syslog 2
syslog_facility LOCAL0
syslog_ident postgres
tcpip_socket on
TimeZone unknown
trace_notify off
transaction_isolation read committed
transaction_read_only off
transform_null_equals off
unix_socket_directory unset
unix_socket_group unset
unix_socket_permissions 511
vacuum_mem 256000
virtual_host unset
wal_buffers 8
wal_debug 0
wal_sync_method fdatasync
zero_damaged_pages off

[GrandFather]

Si tu en as la possibilité, teste dans une base de données créée avec un encodage en UTF8.

[gerald2545]

je suis en phase de test........les encodages ça me saoule vraiment.
Je reviendrai vers vous quand j'aurais fait les tests requis.....
merci encore
mais si vous avez la solution tout prête...faites moi signe

[gerald2545]

le changement d'encodage en utf8 m'a un peu perturbé mon site...bref j'ai essayé de trouver une autre solution.
J'ai fait appel à la mailing list psql-general. On m'a conseillé de passer mon type de varchar en bytea....et le problème est résolu, après quelques aménagements dans mon code.
le lien pour les intéressé(e)s : http://archives.postgresql.org/pgsql...2/msg01354.php

b'nuit