Version imprimable
Exact. Tester *ZERO et '00000' revient au même, sauf que l'on a l'impression de tester une zone numérique avec *ZERO.
Tester *ZEROS et '00000' ne revient pas au même, pour utiliser *ZEROS il faut une zone numérique il me semble, d'où l'objet de ma remarque.
Si, pourtant ! Tester par rapport à la constante figurative *ZERO ou *ZEROS revient au même, qu'on teste une zone numérique ou alphanumérique. En revanche, *ZEROES ne semble pas supporté bien que ce soit l'orthographe correcte en anglais UK au moins ( glurp ! )
Citation:
Envoyé par ILE RPG Reference Guide
Tu as 100 fois raison, j'aurai dû tester !
@ R4ndy :
Comme te le propose K2R400, fais un :
que je compléterais ainsi :Code:
2
pour connaître à la fois le code statut SQLSTT et le code retour SQL "AS400" SQLCOD. Ce dernier code va te monter un code probablement négatif style -104. Or, tous les SQLCOD < 0 sont synonymes d'erreur dans le codage de la requête.Code:Dsply ( SQLSTT + ' ' + %CHAR(SQLCOD) ) ;
Pour retrouver le message associé à ce code, ajoute le préfixe "SQL" en retirant le signe moins de façon à obtenir "SQL0104". Ensuite, fais
pour obtenir le libellé explicatif du message SQL. ça va t'aider.Code:DSPMSGD QSQLSRC SQL0104
Salut !
Donc j'ai mis le DSPLY et l'erreur fournie était une erreur de journalisation (désolé je n'ai pas le code sous la main :mrgreen: ).
Il fallait que la table que je renseigne soit journalisée, donc je l'ai fait et tout fonctionne !(...jusqu'à la prochaine fois ou je viendrai vous embêter :lol:)
Merci pour votre aide. Je laisse le topic tourner encore quelques temps ;).
R4ndy.
SQL aime effectivement beaucoup que les tables soient journalisées pour les mises à jour de BdD.Citation:
Envoyé par R4ndy
{Cependant, pour ne pas journaliser la table il y a 4 possibilités :} edit : phrase remplacée par la suivante pour moins d'ambiguïté
Pour faire des mises à jour de données d'une table en SQL sans journaliser cette cette table, il y a 4 possibilités :
- Soit compiler (CRTSQLRPGI) le programme avec le paramètre "Contrôle de validation " (COMMIT) à *NONE,
- soit ajouter en début de programme l'instruction SQL : exec sql SET OPTION COMMIT = *NONE;
- soit ajouter en début de programme l'instruction SQL : exec sql SET TRANSACTION ISOLATION LEVEL NO COMMIT;
- soit ajouter WITH NC à la fin d'un insert ou update (NC signifiant No Commit). Ce qui donnerait dans ton cas :
Code:
2
3
4
5
6
7
8
9
10************** Début des données ************************************ DPSDNOBLV s 30 /free Exec sql Insert into RANDTEST/PSDGORO (PSDNOBL) Values('TEST') WITH NC; Dsply SQLSTT; /end-free *inlr='1' C RETURN *************** Fin des données *************************************
Non, désolé jump400, mais si on ne veut pas journaliser les tables, et bien on ne les journalise pas. Tu me diras que Monsieur de La Palisse n'aurait pas dit mieux :)
Je m'explique.
Si on ne fait pas STRJRNPF sur les tables concernées, la journalisation n'aura pas lieu, tout simplement. Mais si tu as compilé ton programme (dans lequel il y a des commit et/ou des rollback) avec l'option COMMIT à une valeur autre que *NONE et donc que les fichiers n'ont pas fait l'objet d'un STRJRNPF, chaque fois que le programme passera sur les instructions commit ou rollback, il fera une erreur mais je crois (je n'en suis pas sûr et certain, il faut tester) que ça ne l'empêchera pas de tourner. En revanche, l'inverse n'est pas vrai. En effet, si les fichiers sont journalisés avec STRJRNPF et qu'on ne passe pas sur l'instruction commit dans le programme, et bien les update, delete, insert, create table, etc ne se feront pas. C'est l'erreur classique rencontrée fréquemment : "pourquoi j'ai rien dans mes fichiers ?".
Si les fichiers sont journalisés, SQL déclenche implicitement le STRCMTCTL à la première instruction SQL rencontrée dans le programme, contrairement aux programmes qui n'utilisent pas SQL qui doivent avoir explicitement un STRCMTCTL indiqué dans un CL en amont.
Donc, le mieux et le plus simple, c'est de compiler correctement le programme avec les bonnes options selon que les tables utilisées sont journalisées -- COMMIT(*CHG) par ex. -- ou non -- COMMIT(*NONE) --.
Tout à fait Mercure !
Bien sûr que pour ne pas journaliser un table il suffit de ... ne rien faire (ou alors ENDJRNPF si la table était déjà journalisée )
Il y a juste une méprise sur le sens de ma phrase "Cependant, pour ne pas journaliser la table il y a 4 possibilités :"
Je faisais référence au soucis de R4ndy.
J'aurais du être plus précis en disant :
"Pour faire des mises à jour de données d'une table en SQL sans journaliser cette cette table, il y a 4 possibilités..." ;)
PS : j'ai modifié mon poste pour plus de clarté dans mon explication. Merci Mercure
Concernant la journalisation, les programmeurs ont la facheuse tendance à penser que la journalisation n'est utile qu'à l'écriture (Insert, delete, update etc...).
A l'écriture, c'est très utile pour gérer les transactions :
- Une livraison qui touche le fichier des livraisons, des stocks, des stats, des encours etc.... On met à jour tous les fichiers ou rien, question de conserver une cohérence et une intégrité de la base. Souvent, le paramètre COMMIT(*CHG) est utilisé.
Mais le niveau d'isolation est encore plus utile à la lecture !!!
Dans l'exemple précédent, il y avait avant la transaction 10 en stock.
L'update a fait un -1 mais le commit ou rollback n'a pas eu lieu.
Un autre programme (faisant que des lectures, aucune maj) qui lirait le stock de l'article, s'il n'est pas sous contrôle de valisation ou sous COMIT(*CHG), lirait le stock de l'article à 9 !!!! c'est grave docteur ! c'est ce que l'on appelle une lecture sale. Sans rentrer dans le détail, on peut avoir des lecture sales, des lectures non reproductibles et des lectures fantômes.
La valeur COMIT(*CHG) est à proscrire, le minimum acceptable (pour les lectures) est COMMIT(*CS).
Une bonne application gère donc le transactionnel aussi bien en lecture (il faudra aussi faire des commit après les lectures individuelles ou par paquets) qu'en écriture.
A méditer
Salut !
De toute façon je préfère journaliser ma table pour des raisons de sécurités ;)