Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1049 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL/DB2] Migration

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[MySQL/DB2] Migration

n°1023584
aleske
Posté le 24-03-2005 à 16:18:14  profilanswer
 

Bonjour à tous,
 
Je suis en train de migrer une appli développée en PHP sous MySQL vers DB2. Je me heurte à un problème de type de colonne.
 
Si la colonne ma_colonne est de type int, MySQL n'est pas géné par

Code :
  1. INSERT INTO ma_table (ma_colonne) value ('45');


Par contre DB2 ne veut pas (différence entre le type int de la colonne et le type varchar de '45').
 
Je n'ai pas trop envie de repasser partout pour mettre en conformité les requetes surtout que si on fait ça, c'est parce qu'on construit dynamiquement les requetes.
 
Est-ce qu'il y a un moyen de dire à DB2 de faire les convertions automatiquement comme sous MySQL ?
 
Avant qu'on me pose la question, peu importe la version de DB2, si une version le fait et pas une autre, on s'arrangera avec le client et on utilise le driver ODBC de PEAR.


Message édité par aleske le 24-03-2005 à 17:04:08

---------------
Welcome to reality. It sucks, you'll love it !
mood
Publicité
Posté le 24-03-2005 à 16:18:14  profilanswer
 

n°1024503
aleske
Posté le 25-03-2005 à 10:26:06  profilanswer
 

:bounce: Personne ?
 
Bouhouhouhouhou  :cry:


---------------
Welcome to reality. It sucks, you'll love it !
n°1024586
Arjuna
Aircraft Ident.: F-MBSD
Posté le 25-03-2005 à 11:23:15  profilanswer
 

Tu crées des VARCHAR, puis tu fais un ALTER en changeant le type. C'est maxi-crade, mais ça résoudra ton problème de façon simple.
 
Conseil : n'ACTIVE PAS LE "NOCHECK" sur un changement de type. Oracle le permet par exemple, et c'est comme ça que je me suis retrouvé avec "NON RENSEIGNE" dans un champ de type "FLOAT". Bah ça faisait planter TOUS les outils qui utilisaient la base, y compris les requêteurs d'Oracle, et ça a été donc une galère pas croyable pour retrouver la source du problème ;)

n°1028363
aleske
Posté le 29-03-2005 à 14:29:06  profilanswer
 

Bon, j'ai abandonné l'idée, je me retape les requetes au fur et à mesure que je vois qu'elles plantent.
 
Ce qui m'amène au problème du jour :  
Si je fais un

Code :
  1. SELECT * FROM ma_table WHERE mon_clob='toto';


ca me dit

Code :
  1. [nativecode=42818 [IBM][CLI Driver][DB2/NT] SQL0401N Les types de données des opérandes associés à l'opérateur "=" ne sont pas compatibles. SQLSTATE=42818]


 
Une raison ? Une idée ?


---------------
Welcome to reality. It sucks, you'll love it !
n°1028535
glod 2
Votre trajet, notre projet.
Posté le 29-03-2005 à 16:02:46  profilanswer
 

ben c'est pourtant clair, il veut pas d' "=" pour comparer des chaînes, te faut un autre opérateur, comme LIKE.

n°1028638
Arjuna
Aircraft Ident.: F-MBSD
Posté le 29-03-2005 à 16:28:40  profilanswer
 

Nan, c'est pas ça, c'est un clob, c'est un volume de données qui peut aller jusqu'à 2 Go (du moins, avec SQL Server). Et t'as pas le droit de faire ni "=" ni "like" ni quoi que ce soit dessus. Pas d'"order by" dedans non plus. C'est juste fait pour lire et écrire dedans. (du moins, avec Oracle, parcequ'avec SQL Server, au lieu de prendre le type "image" (binaire) tu prend le type "text" (asci) ou "ntext" (unicode) et à ce moment, le = et le like sont authorisés, bien que formellement déconseillés par Microsoft (va me faire une recherche de chaîne dans un truc de 2 Go toi ;))


Message édité par Arjuna le 29-03-2005 à 16:30:18
n°1028676
aleske
Posté le 29-03-2005 à 16:41:39  profilanswer
 

J'ai découvert que DB2 permet des varchar de 32000 caractères et des brouettes donc je vais contourner le problème comme ça.
 
Pas d'inquiétude, je ne vais pas comparer des chaines de 32000 caractères, c'est juste qu'avant, sous MySQL, j'avais besoin de faire des like sur des colonnes de plus de 255 caractères (environ 4-500 caractères) donc j'avais un champ TEXT que j'ai changé en CLOB sans me poser de question.  :pfff:  
 
Promis, la prochaine fois, je réfléchis (un peu)  :p


---------------
Welcome to reality. It sucks, you'll love it !
n°1028847
Arjuna
Aircraft Ident.: F-MBSD
Posté le 29-03-2005 à 18:25:50  profilanswer
 

Ah ok :)
 
C'est pas mal le coup du 32 000 chars, parceque SQL Server, c'est 8000 et Oracle 4000, et c'est chiant quand tu veux sauvegarder le contenu d'un mail par exemple, ou autres infos assez longues sans être énormes. D'autant plus qu'avec Oracle, il gère les clob comme une bille (comme DB2 quoi... on peut rien faire avec :D)


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [MySQL/DB2] Migration

 

Sujets relatifs
[MySql]Pb syntaxe que j'arrive pas a résoudre[MySql - Access] Problèmes de dates
installer MySQL sous mandrakeExecuter des Jobs, des StoreProc,des scripts sous MySQL?
Not IN Not Exists sous MySQL?[MySQL] DELETE récursif
MysqlDécrementation sous mysql, est ce possible ?
Performance MySQL queries via API CProbleme php/MySQL : "Warning mysql_num_rows()"
Plus de sujets relatifs à : [MySQL/DB2] Migration


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR