[DB2]requete avec 'LIMIT' ?!

[beastman007]

Bonjour à tous,

je souhaiterai utiliser la restriction LIMIT dans ma requete sql mais il n'en veut pas ni de ça ni de 'top' .

Que puis-je utiliser ?

Ma requete :

Code :

1
2
3
4
5
6
7
8
 
SELECT LMBANO 
FROM MILOMA 
WHERE LMITNO='".$txtCdp."' 
AND LMCONO=400 
AND LMBANO LIKE  '".$annee."%' 
ORDER BY LMBANO DESC 
LIMIT 1,10

Merci de votre aide

[fadace]

Code :

1
2
3
4
5
6
7
SELECT LMBANO 
FROM MILOMA 
WHERE LMITNO='".$txtCdp."' 
AND LMCONO=400 
AND LMBANO LIKE  '".$annee."%' 
ORDER BY LMBANO DESC 
FETCH FIRST 10 ROWS ONLY

[beastman007]

Merci beaucoup !

[yellow_panther]

Bonjour,
Y a-t-il un moyen de prendre les lignes 10 à 20 comme avec LIMIT ?

Code :

1
2
3
4
5
 
SELECT ...
FROM ...
WHERE ...
LIMIT 10,10

[iubito]

et pour les requêtes update ? est-ce possible de limiter la mise à jour à x enregistrements ?
Et y a-t'il une syntaxe standardisée utilisable sur DB2 et sur MySQL ?

merci d'avance

[DeLorbe]

Envoyé par yellow_panther

Bonjour,
Y a-t-il un moyen de prendre les lignes 10 à 20 comme avec LIMIT ?

Code :

Bonjour,

Je me permets de reprendre ce post, car j'ai aussi le même problème.
J'utilise TSO pour accéder à des bases sous DB2.

Je dois lister tous les enregistrements d'une table, et TSO plante systématiquement si je monte la limite du nombre de résultats au-delà de 5000. Il y a un peu moins de 666 000 enregistrements.
Je dois donc les récupérer par étapes (par paquets de 5000 par exemple).

J'ai trouvé en cherchant les fonctions SetFetchSize() et SetMaxResults() qui ont l'air d'appartenir davantage à JAVA qu'au SQL de DB2. Je ne crois pas que je pourrai les utiliser, car le seul langage que j'utilise dans ce cas, c'est le SQL.

Y a-t-il un équivalent de LIMIT n1,n2 en SQL chez DB2?

Merci

[Luc Orient]

Envoyé par DeLorbe

...
Je me permets de reprendre ce post, car j'ai aussi le même problème.
J'utilise TSO pour accéder à des bases sous DB2.

Je dois lister tous les enregistrements d'une table, et TSO plante systématiquement si je monte la limite du nombre de résultats au-delà de 5000. Il y a un peu moins de 666 000 enregistrements.
Je dois donc les récupérer par étapes (par paquets de 5000 par exemple).
...

Quelque chose doit m'échapper car je vois mal l'interêt de lister une table de près de 700 000 lignes à l'écran, mais bon ...
Sinon, sous TSO / SPUFI il y a un paramètre pour limiter le nombre de lignes retournées ...

[DeLorbe]

Envoyé par Luc Orient

Quelque chose doit m'échapper car je vois mal l'interêt de lister une table de près de 700 000 lignes à l'écran, mais bon ...
Sinon, sous TSO / SPUFI il y a un paramètre pour limiter le nombre de lignes retournées ...

Salut,

D'abord, merci pour ta réponse.

Je précise : je veux récupérer tout ça pour en faire un tableau Excel, ce qui m'évitera d'avoir à faire à chaque fois la manipulation d'exportation, puis de mise en forme des résultats. C'est long, lourd, et on peut modifier la demande à chaque instant.
Car ces données qu'on me demande ne sont jamais les mêmes, et font l'objet d'analyses a posteriori dans un tableau croisé, ou à l'aide de filtres divers.

J'ai modifié le paramètre en question dans SPUFI, mais au-delà de 5000, il plante systématiquement.

[jab]

Il est possible d'utiliser une procédure stockée et un curseur:

Voir ce post.

[Luc Orient]

Envoyé par DeLorbe

...
Je précise : je veux récupérer tout ça pour en faire un tableau Excel, ce qui m'évitera d'avoir à faire à chaque fois la manipulation d'exportation, puis de mise en forme des résultats. C'est long, lourd, et on peut modifier la demande à chaque instant ...

Moi je ne ferais pas cela sous TSO / SPUFI.

Je passerais par un job batch avec un DSNTIAUL qui permet d'écrire les données dans un fichier. La seule petite difficulté, c'est qu'il faut décoder les colonnes en DECIMAL et INTEGER en utilisant la fonction scalaire CHAR.

En plus, avec une petite astuce, on peut même générer le séparateur ';' entre les colonnes extraites ce qui permet à EXCEL de reconnaitre le fichier comme de type CSV et de faire l'import en un seul clic

Question : un fichier issu d'une table de 700 000 lignes ce n'est pas trop gros pour EXCEL ?

[jab]

Envoyé par Luc Orient

Question : un fichier issu d'une table de 700 000 lignes ce n'est pas trop gros pour EXCEL ?

Bien vu. Il me semble que la limite est de l'ordre de 65000

[DeLorbe]

Salut,

En effet, c'est ce que j'ai vu vendredi : c'est trop gros pour un fichier Excel.
En plus, cette base est mise à jour quotidiennement, il faudrait donc que je refasse la manip régulièrement pour récupérer les nouvelles entrées.

Résultat : je lâche l'affaire, je ferai des requêtes à la demande.
J'ai revu toute la procédure, j'exporte les résultats de la requête dans un fichier texte, qu'il faut que je retouche un peu avant de l'importer dans Excel.
Ensuite, je fais le nettoyage sous Excel, c'est assez rapide.

Mais je vais quand même voir vos solutions de plus près, pour ma culture perso.
Pour le DSN ça va être chaud : c'est une banque, et l'accès des utilisateurs est ultra restreint. ême un DSN utilisateur, je ne pense pas qu'on me ferait ça.
Je vais voir quand même.

Merci à tous pour vos réponses et pour votre aide

Nico

[ALHER]

Perso,

Pour mes statistiques et rapports sur mes databases DB2 , j'utilise ACCESS.
La DB une fois définie en OBDC, je link les tables et je peux les utliser comme des tables ACCESS dans des queries ACCESS.
Les fonctions macros , formulaires et rapports sont alors disponibles.

Il m'arrive même d'y faire des updates.

Fini la limitation de 65000

[jab]

Envoyé par ALHER

Perso,

Pour mes statistiques et rapports sur mes databases DB2 , j'utilise ACCESS.
La DB une fois définie en OBDC, je link les tables et je peux les utliser comme des tables ACCESS dans des queries ACCESS.
Les fonctions macros , formulaires et rapports sont alors disponibles.

Il m'arrive même d'y faire des updates.

Fini la limitation de 65000

De même, pour des requêtes ponctuelles, j'utilise volontier Access.