2016-06-28 1 views
1

je reçois cette erreur de base de données Progress lors de l'exécution de la requête suivante en utilisant ODBC:Erreur ODBC « colonne x dans le tableau y a une valeur supérieure à sa longueur maximale ou de précision »

SELECT distinct Table.column, 
     { fn CONVERT(SUBSTRING(Table.ProblematicColumn, 1, 60), SQL_VARCHAR)} as test 
FROM PUB.Table 
WHERE (Table.id IN (
      SELECT Table.id 
      FROM PUB.Table 
      )) 

Je sais qu'il est possible de le fixer à l'aide les DBTools. Cependant, je lance des requêtes sur plusieurs bases de données Progress de plusieurs clients, il n'est donc pas pratique de le faire à chaque fois. Aussi, pour une raison quelconque, le client ODBC que j'utilise (PHP), ne montre aucune erreur quand cela arrive. Au lieu de cela, il renvoie un résultat vide.

La conversion que j'ai faite à un VAR_CHAR de 60 caractères a aidé jusqu'à ce que j'ai ajouté la sous-requête. Lorsque la sous-requête est là, je reçois la même erreur.

Fait intéressant, quand le 'distinct' n'est pas là, ça marche. Mais j'ai besoin du distinct.

Éditer: La question est comment puis-je exécuter cette requête sans réparer la colonne de largeur avec DBTool.

+0

Vous savez donc quel est le problème et vous savez comment le réparer. Mais vous ne voulez pas le réparer. Aidez-nous ici ... quelle est votre question? –

+0

La question est simple - comment exécuter la requête et éviter cette erreur. Comme mentionné - en utilisant le '{fn CONVERT}' a aidé pour la requête principale. Comment cela peut-il être résolu quand il y a une sous-requête impliquée – David

+0

La réponse à cette question est également simple et bien connue. –

Répondre

0

Mise à niveau vers OE 11.6.

Il existe des options dans 11.6 pour tronquer automatiquement et silencieusement les données afin d'éviter toute erreur.

"autonome schéma de mise à jour"

https://community.progress.com/community_groups/openedge_rdbms/f/18/t/19534

+0

Merci Tom. Malheureusement, il ne sera pas possible pour moi de mettre à jour la base de données pour tous nos clients. En outre, je ne suis pas sûr qu'ils aimeront l'idée que leurs données sont tronquées silencieusement. Je me demandais quelle était l'idée de laisser l'utilisateur insérer des données plus que la largeur de la colonne, mais ensuite lors de l'interrogation des données pour montrer une erreur. Je peux comprendre la flexibilité nécessaire pour ajouter des données plus que la largeur d'origine, mais je m'attendrais à ce que la largeur soit également modifiée (similaire à no-sql). – David

+0

Modification de la largeur à la volée est également une option. –

+0

Si vous souhaitez que votre comportement soit le même que celui que vous décrivez, vous devez soit exécuter dbtool ou mettre à niveau, soit trouver un client SQL qui n'est pas trop bridé à propos de la largeur du champ. –

1

Il a fallu quelques minutes pour trouver une réponse. Le problème semble être dans le courtier SQL OE10 ne pas gérer le sous-select dans la clause where. Cette alternative utilisant une jointure interne à un sous-select semble être équivalente à moi. Je l'ai testé, ça marche. Remplacer le client SQL ne fera rien, l'erreur se produit dans le courtier OpenEdge SQL: Je reçois la même erreur en utilisant le pilote JDBC OpenEdge.

SELECT distinct Table.column, 
    { fn CONVERT(SUBSTRING(Table.ProblematicColumn, 1, 60), SQL_VARCHAR)} as test 
FROM PUB.Table inner join (select id from PUB.Table) t2 on Table.id = t2.id 
+0

Merci John. Malheureusement, mon cas spécifique est plus complexe, l'exemple que j'ai mentionné ici est une version très simplifiée de la vraie requête. J'ai essayé votre approche et déplacé la sous-requête du WHERE au JOIN, changé de INNER JOIN à LEFT JOIN parce que la partie de sous-requête dans la clause WHERE était 'OU' pas 'ET'. Cependant, il n'élargit pas le jeu de résultats et je crois que c'est parce que la clause WHERE réduit le jeu de résultats. Quoi qu'il en soit, votre réponse est 100% correcte et déplacer la sous-requête vers la clause JOIN ne résout le message d'erreur. – David