Forums PostgreSQL.fr

gleu

Administrateur

Re : C vs C++

Quelle est la requête complète ?

---

Guillaume.

Postgres.0

Membre

Re : C vs C++

Update table set (clé, date1) =(1999422, Aµ(U)

Dernière modification par Postgres.0 (09/08/2011 10:13:44)

Postgres.0

Membre

Re : C vs C++

la valeur de la  date avant d'être transformée en binaire était :

2011-04-01 09:21:26

Dernière modification par Postgres.0 (09/08/2011 10:20:11)

Postgres.0

Membre

Re : C vs C++

Cette date pose un problème aussi bien au curseur binaire qu'au curseur normal.

j'ai des cotes autour de mes  dates (literal) et autre varchar.
sauf que quand j'appelle PQescapeByteaConn, elle me double les cotes autour de la date...
Et quand je parcours la chaine pour transformer les doubles cotes en cotes simple, il me sort des erreurs sur mes données bytea, sur les antislash.

Est ce qu'on peut appliquer succesivement PQescapeliteral et PQescapeByteaConn a la même chaine de caractère.
Je pose cette question, car, dans ma requetes Insert, il y a des champs de type varchar, bytea, char, date, int...

Dernière modification par Postgres.0 (09/08/2011 16:26:37)

gleu

Administrateur

Re : C vs C++

PQescapeliteral est uniquement pour les chaînes de caractères, PQescapeByteaConn pour les bytea. Ça ne doit pas être utilisé avec les autres types.

---

Guillaume.

Postgres.0

Membre

Re : C vs C++

gleu :

j'ai une nouvelle erreur : : ERROR:  invalid byte sequence for encoding "UTF8": 0x00

En cherchant sur internet, j'ai compris que j'envoie au serveur un caractère de fin de chaine qu'il ne sait pas lire.
Est-ce-que vous avez une idée de comment le supprimer de ma requete ?

Postgres.0

Membre

Re : C vs C++

Pour faire plus simple je vous mets ma requete, je ne sais ps si vous pouvez la tester chez vous

INSERT INTO Table(raisondemautob,pc,xi,trans,merchant) values (E'\000 \000\001',E'\001c\000\000\000\002@\000\000\000\342`\342\374\241\2656\307?\363b\210\207*\223G\345\177J\205\333\232!{u1u\325\203\207 k\324 8f\307^L\266,\326\221\234\222\370\360\372:.3'\302\236\262*oW\372\031\363\341%\370\003\004\000\000\000\000\000\000\000\004\020\000\000\000\273\273r\331\355\0047\346\364\253L\310+\262{\261\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000',E'',E'',E'\001\303\001\000\000\002\240\001\000\000\261+K\034\352\012\246\023\344;\224\267B).3K\324`,\236P\302#)\370\304\001:\242\375\347\344\210\177\007\034\2553\304\377^\211\036\012\374\323\321\333#\356\353\011\025D5\220\253\272;6Ax~\002\003\312\356\213{p\314\305\210\244\2648\347\370\3446\246\011\002\365u^\201B\355\003_(\234\010\243?\026\343\261[p\206\372\354|\333\202\215\360g \344\300pSl\262\252\246\330\317\270\360\254q\254\276\373\011\325}\024\027*\350\354\323\374\214\375R\353\331\207d\367\340\243\211<\270!<\004\253\0102>\313\316 \2526\320\325\\?\345\265\341\252C\026\214\200-\024y\030\252\371\210\023wD\364\370Z?\007\303\222yn\025+\012\205y\367\010\013C'\316,\214\220L(Y\277\333lO\347P\021O}\276\334'\226\2677\232V\220(\200\231\356\200]\022\321\001\240]o\252\272\212\341\206X\234\026bG\377+\030\350\224\277\340\021\252qK\305\254\327C\365\351cm\334\207\253\252\274\011\346\256n\177\263 \357\227\204w\365\262s\223\321Dm\307O{c\270\331\211_'\010\017\224z\301\361@~\260\204WkA\300\2265rG\020\273\256\013\260y\032\366\327\200\025\256\314)Y\320\276\301\206\273\301[\374s \256l\314\202(\213\247\362\341\320+\367\344^\235P\270y\245\274g\354\335\014.\3442\2411\342\206\230\347\355\242*$/\215V\304\366\325/\212Av\200g\203\035!\275\324M\205Y\004C\376\243u0\344-\213\262\254x\003\003\004\000\000\000\000\000\000\000\004\020\000\000\000K\367\371\223\327\010\353\215\2678(\252"\363A\312')

Postgres.0

Membre

Re : C vs C++

tous les champs sont des bytea.

Postgres.0

Membre

Re : C vs C++

Je ne pense pas que les données soient vraiment au bon format binaire.

Dernière modification par Postgres.0 (11/08/2011 10:08:07)

gleu

Administrateur

Re : C vs C++

Pour infos, il ne fait pas ajouter de E avant la chaîne de données binaires.

---

Guillaume.

Postgres.0

Membre

Re : C vs C++

ok, je penses que mes données en bytea sont altérées !

J'ai une question concernant PQgetResult() :

Imaginez que j'envoie, avec PQsendQuery, la commande composée de "Begin; Insert1; Insert2; Insert3; End;"
En suite, je boucle sur PQgetResult()  mais la je remarque que Insert1 s'est mal passé : il m'affiche, en bonne et dûe forme, le message suivant, grace à PQresultErrorMessage : "duplicate key value violates unique constraint".
Ma question est : si le deuxième Insert s'est mal passé, comment je pourrais faire pour recupérer le message d'erreur avec PQresultErrorMessage, car là, cette aapi me renvoie une chaine vide.

gleu

Administrateur

Re : C vs C++

Ce serait bien de créer un nouveau thread pour chaque nouvelle question.

Néanmoins, pour répondre à votre question, PQerrorMessage renvoie le bon message d'erreur en ce qui me concerne.

---

Guillaume.

Postgres.0

Membre

Re : C vs C++

Ok, je le ferrai .

En fait, je boucle comme ça while(NULL != (result = PQgetResult(conn))), mais si il trouve une erreur à la première instruction, il sort de la boucle du coup je ne peux plus savoir si les autres instructions ce sont bien passées.

Postgres.0

Membre

Re : C vs C++

Je me suis dit que je dois peut être utilisé  PQconsumeInput(conn_in) et !PQisBusy(conn_in) pour pouvoir gérer ce problème.