Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Nbr de base dépassée ...

Nbr de base dépassée ...

15 réponses
Avatar
Francky
Bonjour,

Au cours du d=E9roulement du proc un peu complexe j'obtiens=20
ce message d'erreur.
Ma proc se termine quand m=EAme comme il faut.
Je ne comprends pas le sens de ce message ...

Serveur : Msg 925, Niveau 19, =C9tat 1, Ligne 1
Le nombre maximal de bases de donn=E9es utilis=E9es dans=20
chaque requ=EAte a =E9t=E9 d=E9pass=E9. Le maximum autoris=E9 est 8.

merci d'avance pour votre aide.

Fr@ncky
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Patrice
Je suis bien aise de voir que cette petite remarque ne pose pas de sushi ;-)

Patrice

--

"Fred BROUARD" a écrit dans le message de
news:


Patrice a écrit:
> Fred est de bon conseil mais - pardon Fred - fait
> parfois part de son désaccord d'une façon un peu "tranchée".

tranché ? Moi ??? non !!!
Plutôt couperet à tendance guillotine !!! ;-)

A +

>
> Patrice

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************



Avatar
Fr
"Fred BROUARD" a écrit dans le message de
news:%
bonjour

a écrit:
> Moi je n'appel pas cela de la programmation spaghetti !
> Quand j'ai un problème je le découpe en plusieurs petits problèmes pour
> lesquels les soltuions sont plus facile à trouver. Cela me permet aussi


de
> les ranger dans des catégorie (proc de manip de chaine, de manip de


donnée,
> de calcul, etc ...)
>
> Chaque proc à un boulot précis.

penser fonction (UDF) pour cela, pas proc...

en principe une proc devrait faire 1 boulot en entier et ne gérer qu'une
transaction.



Je ne peux pas toujours mettre dans des fonctions. les manip de chaine et
les calculs oui... mais les maj de base (updtae/insert/delete) etc ... non


>
> J'ai aussi réparti dans plusieur bases afin d'y voir plus clair.

ça c'est l'erreur majeure !

Le découpage en différentes bases (à moins d'un volume tres important de


données
de plusieurs dizaine de giga octets pas base) est une abération.

Une base est fait pour concentrer les données d'un même processus


informatique.

Par exemple base comptable => compta, facturation, voire paye
base commerciale => prospects, clients, devis

Chaque base est propre à un service précis de l'entreprise et pour une


même
fonction globale.



Effectivement j'ai peut-être un peu trop découpé les choses dasn différentes
bases :-((

>
> J'ai une base TOOLS ou je stocke différents outils (ainsi, si je veux
> retrouver mes outils sur un autre serveur je n'ai qu'a copier cette


base) ,
> une bases DATA dans laquelle se trouve les données et quelques proc de
> manipulation de ces données et une base APPLI dans laquelle je trouve le
> coté applicatif .
>
> Devrais-je tout mettre dans une seule base ? Devrais-je moins découpé


les
> taches en plusieurs proc ?

oui, oui


Ok, pour les bases mais je ne suis pas persuadé qu'il soit préférable
d'avoir une proc de 2000 lignes plutôt que 20 proc bien défnie.

Quel est le plus pénalisant ? le découpage en plusieurs base ou , dans une
meme base, le decoupage en plusieur petite proc ?

Quel est le volume de tes bases ?


Environs 12 Go toutes rassemblées

@+




A +

>
> @+
>
>
>
> "Fred BROUARD" a écrit dans le message de
> news:
>
>>
>> a écrit:
>>
>>>Je n'ai pas de requete faisant intervenir plusieurs bases, j'en ai
>
> quelques
>
>>>unes faisant intervenir plusieur tables (et encore, moins de 8) .
>>>
>>>Par contre je fait appel à des procédures qui appel d'autre proc qui
>
> elles
>
>>>mêmes en appelles d'autre etc ... peut-être au delà de 8 niveaux et


dans
>
> 3
>
>>>bases différentes maximum sur un meme serveur.
>>>
>>>cela pourrait t'il etre la cause du message ?
>>
>>
>>He oui, cela s'apelle la programmation spaghetti !
>>
>>Même avec trois bases, il peut voir 8 appels successifs d'une base à
>
> l'autre.
>
>>Exemple :
>>
>>Base A, Procedure A1 appel => Base B, Procédure B1 => Base A procedure


A2
>>
>>pour lui, c'est 3 bases ouvertes qu'il faut maintenir avec chacune leur
>
> espace
>
>>de travail.
>>
>>Non seulement c'est du spaghetti, mais le meilleur moyen de bouffer


toute
>
> la RAM
>
>>pour rien et faire un veau applicatif !
>>
>>A +
>>
>>>
>>>"Fred BROUARD" a écrit dans le message de
>>>news:
>>>
>>>
>>>>C'est assez clair : SQL Server admet que l'on travaille avec jusqu'à 8
>>>
>>>bases de
>>>
>>>
>>>>donnés différentes dans une même requête. Apparament ce max a été
>
> dépassé
>
>>>!
>>>
>>>
>>>>A +
>>>>
>>>>Francky a écrit:
>>>>
>>>>
>>>>>Bonjour,
>>>>>
>>>>>Au cours du déroulement du proc un peu complexe j'obtiens
>>>>>ce message d'erreur.
>>>>>Ma proc se termine quand même comme il faut.
>>>>>Je ne comprends pas le sens de ce message ...
>>>>>
>>>>>Serveur : Msg 925, Niveau 19, État 1, Ligne 1
>>>>>Le nombre maximal de bases de données utilisées dans
>>>>>chaque requête a été dépassé. Le maximum autorisé est 8.
>>>>>
>>>>>merci d'avance pour votre aide.
>>>>>
>>>>>
>>>>
>>>>--
>>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>>>************************ www.datasapiens.com *************************
>>>>
>>>
>>>
>>>
>>--
>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>************************ www.datasapiens.com *************************
>>
>
>
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************



Avatar
Fred BROUARD
a écrit:
"Fred BROUARD" a écrit dans le message de
news:%

bonjour

a écrit:

Moi je n'appel pas cela de la programmation spaghetti !
Quand j'ai un problème je le découpe en plusieurs petits problèmes pour
lesquels les soltuions sont plus facile à trouver. Cela me permet aussi





de

les ranger dans des catégorie (proc de manip de chaine, de manip de





donnée,

de calcul, etc ...)

Chaque proc à un boulot précis.



penser fonction (UDF) pour cela, pas proc...

en principe une proc devrait faire 1 boulot en entier et ne gérer qu'une
transaction.




Je ne peux pas toujours mettre dans des fonctions. les manip de chaine et
les calculs oui... mais les maj de base (updtae/insert/delete) etc ... non



OK pour les fonctions, éviter les maj de lignes de table

j'aimerai voir le code de quelques unes de tes proc
je soupçonne l'utilisation massive de curseur à la place de requêtes SQL !




J'ai aussi réparti dans plusieur bases afin d'y voir plus clair.



ça c'est l'erreur majeure !

Le découpage en différentes bases (à moins d'un volume tres important de



données

de plusieurs dizaine de giga octets pas base) est une abération.

Une base est fait pour concentrer les données d'un même processus



informatique.

Par exemple base comptable => compta, facturation, voire paye
base commerciale => prospects, clients, devis

Chaque base est propre à un service précis de l'entreprise et pour une



même

fonction globale.




Effectivement j'ai peut-être un peu trop découpé les choses dasn différentes
bases :-((


J'ai une base TOOLS ou je stocke différents outils (ainsi, si je veux
retrouver mes outils sur un autre serveur je n'ai qu'a copier cette





base) ,

une bases DATA dans laquelle se trouve les données et quelques proc de
manipulation de ces données et une base APPLI dans laquelle je trouve le
coté applicatif .

Devrais-je tout mettre dans une seule base ? Devrais-je moins découpé





les

taches en plusieurs proc ?



oui, oui



Ok, pour les bases mais je ne suis pas persuadé qu'il soit préférable
d'avoir une proc de 2000 lignes plutôt que 20 proc bien défnie.

Quel est le plus pénalisant ? le découpage en plusieurs base ou , dans une
meme base, le decoupage en plusieur petite proc ?


Quel est le volume de tes bases ?



Environs 12 Go toutes rassemblées



c'est correct, dans les bases de taille moyenne.
Décrit moi ton serveur (PC) et le nombre des user.
Je suppose qu'en rassemblant les bases tu va éviter un peu de redondance ?




@+




A +


@+



"Fred BROUARD" a écrit dans le message de
news:


a écrit:


Je n'ai pas de requete faisant intervenir plusieurs bases, j'en ai





quelques


unes faisant intervenir plusieur tables (et encore, moins de 8) .

Par contre je fait appel à des procédures qui appel d'autre proc qui





elles


mêmes en appelles d'autre etc ... peut-être au delà de 8 niveaux et









dans

3


bases différentes maximum sur un meme serveur.

cela pourrait t'il etre la cause du message ?




He oui, cela s'apelle la programmation spaghetti !

Même avec trois bases, il peut voir 8 appels successifs d'une base à



l'autre.


Exemple :

Base A, Procedure A1 appel => Base B, Procédure B1 => Base A procedure







A2

pour lui, c'est 3 bases ouvertes qu'il faut maintenir avec chacune leur



espace


de travail.

Non seulement c'est du spaghetti, mais le meilleur moyen de bouffer







toute

la RAM


pour rien et faire un veau applicatif !

A +


"Fred BROUARD" a écrit dans le message de
news:



C'est assez clair : SQL Server admet que l'on travaille avec jusqu'à 8



bases de



donnés différentes dans une même requête. Apparament ce max a été







dépassé


!



A +

Francky a écrit:



Bonjour,

Au cours du déroulement du proc un peu complexe j'obtiens
ce message d'erreur.
Ma proc se termine quand même comme il faut.
Je ne comprends pas le sens de ce message ...

Serveur : Msg 925, Niveau 19, État 1, Ligne 1
Le nombre maximal de bases de données utilisées dans
chaque requête a été dépassé. Le maximum autorisé est 8.

merci d'avance pour votre aide.





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************








--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************








--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************









--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Fr
Bonjour Fred,

>
> Je ne peux pas toujours mettre dans des fonctions. les manip de chaine


et
> les calculs oui... mais les maj de base (updtae/insert/delete) etc ...


non

OK pour les fonctions, éviter les maj de lignes de table

j'aimerai voir le code de quelques unes de tes proc
je soupçonne l'utilisation massive de curseur à la place de requêtes SQL !



J'évite au maximum l'utilisation de curseur, j'utilise de préférence des
requete dans lesquelles je doit de temps en temps appeller des fonctions
pour m'en sortir.

Je suis sensibilisé à pas mal de problèmes et de méthodes de prog mais je ne
pensais pas que l'appel de proc "inter-bases" pouvais consommer autant de
ressources.

Mon appli nécéssite très certainement un grand ménage; voir même un
redeveloppement en parrallèle de l'appli en prod... mais là c'est une
question de cout/homme.
Cela fait plus de 2 ans qu'on lui colle des "rustines" toujours en
urgence... Nos commerciaux vendent des fonctionalités avant même qu'elles
existent ! D'ou une certaine pression au service info :-(

Mais là c'est un autre débat politico-commercialo-marketingo-managerio ! Ce
n'est pas moi le boss ... (qui sait un jour peut-être ;-) )


>>Quel est le volume de tes bases ?
>
> Environs 12 Go toutes rassemblées

c'est correct, dans les bases de taille moyenne.
Décrit moi ton serveur (PC) et le nombre des user.
Je suppose qu'en rassemblant les bases tu va éviter un peu de redondance ?



Serveur de prod :
Bi-Xéon 2,4GHZ en Hyper Threading 2Go RAM 2 Espace RAID 5 de 100 Go (Carte
Raid PROMISE SX6000 ): Un pour les bases, un autre pour les journaux de
transac et quelque archivages de fichiers.
Le système (W2K Server) est installé sur un 7eme disque IDE classique de 50
Go

Serveur de dev : (celui sur lequel j'ai eu mes messages d'erreurs)
Mono P4 2,4GHZ 768 Mo RAM 1 seul espace RAID 5 de 40 Go

Etant donné que l'appli est un extranet pour nos clients le nombre de
connexion est variable mais il dépasse rarement les 50 simultanées.

Avant cette appli j'en ai fait une autre qui fonctionne, depuis 3 ans (sans
problème) avec une seule base et qui brasse de gros volume d'info.
Elle importe via des lot DTS des tickets d'info (environs 100 par secondes)
ce qui me génére entre 40 et 60 Go de données par mois. mais là j'ai été
obligé de découpé en plusieur FILEGROUP et je ne garde que les 3 derniers
mois glissants.

Pour l'extranet j'ai changé de méthode et découpé en plusieurs bases dans un
soucis de clarté, pensant bien faire ... no comment ;-)

Encore merci Fred de ta contribution à ce newsgroup qui permet à plusieurs
d'entre nous de se sortir de mauvaise passe ou de se défaire de mauvaise
habitude ... meme si, parfois, il ne faut pas être trop suceptible :-))

@+






>
> @+
>
>
>
>
>>A +
>>
>>
>>>@+
>>>
>>>
>>>
>>>"Fred BROUARD" a écrit dans le message de
>>>news:
>>>
>>>
>>>> a écrit:
>>>>
>>>>
>>>>>Je n'ai pas de requete faisant intervenir plusieurs bases, j'en ai
>>>
>>>quelques
>>>
>>>
>>>>>unes faisant intervenir plusieur tables (et encore, moins de 8) .
>>>>>
>>>>>Par contre je fait appel à des procédures qui appel d'autre proc qui
>>>
>>>elles
>>>
>>>
>>>>>mêmes en appelles d'autre etc ... peut-être au delà de 8 niveaux et
>
> dans
>
>>>3
>>>
>>>
>>>>>bases différentes maximum sur un meme serveur.
>>>>>
>>>>>cela pourrait t'il etre la cause du message ?
>>>>
>>>>
>>>>He oui, cela s'apelle la programmation spaghetti !
>>>>
>>>>Même avec trois bases, il peut voir 8 appels successifs d'une base à
>>>
>>>l'autre.
>>>
>>>
>>>>Exemple :
>>>>
>>>>Base A, Procedure A1 appel => Base B, Procédure B1 => Base A procedure
>
> A2
>
>>>>pour lui, c'est 3 bases ouvertes qu'il faut maintenir avec chacune


leur
>>>
>>>espace
>>>
>>>
>>>>de travail.
>>>>
>>>>Non seulement c'est du spaghetti, mais le meilleur moyen de bouffer
>
> toute
>
>>>la RAM
>>>
>>>
>>>>pour rien et faire un veau applicatif !
>>>>
>>>>A +
>>>>
>>>>
>>>>>"Fred BROUARD" a écrit dans le message de
>>>>>news:
>>>>>
>>>>>
>>>>>
>>>>>>C'est assez clair : SQL Server admet que l'on travaille avec jusqu'à


8
>>>>>
>>>>>bases de
>>>>>
>>>>>
>>>>>
>>>>>>donnés différentes dans une même requête. Apparament ce max a été
>>>
>>>dépassé
>>>
>>>
>>>>>!
>>>>>
>>>>>
>>>>>
>>>>>>A +
>>>>>>
>>>>>>Francky a écrit:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Bonjour,
>>>>>>>
>>>>>>>Au cours du déroulement du proc un peu complexe j'obtiens
>>>>>>>ce message d'erreur.
>>>>>>>Ma proc se termine quand même comme il faut.
>>>>>>>Je ne comprends pas le sens de ce message ...
>>>>>>>
>>>>>>>Serveur : Msg 925, Niveau 19, État 1, Ligne 1
>>>>>>>Le nombre maximal de bases de données utilisées dans
>>>>>>>chaque requête a été dépassé. Le maximum autorisé est 8.
>>>>>>>
>>>>>>>merci d'avance pour votre aide.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>--
>>>>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi,


web
>>>>>>Livre SQL - col. Référence :


http://sqlpro.developpez.com/bookSQL.html
>>>>>>Le site du SQL, pour débutants et pros :


http://sqlpro.developpez.com
>>>>>>************************ www.datasapiens.com


*************************
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>>>************************ www.datasapiens.com *************************
>>>>
>>>
>>>
>>>
>>--
>>Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
>>Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
>>Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
>>************************ www.datasapiens.com *************************
>>
>
>
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************



Avatar
Fred BROUARD
salut,

a écrit:


J'évite au maximum l'utilisation de curseur, j'utilise de préférence des
requete dans lesquelles je doit de temps en temps appeller des fonctions
pour m'en sortir.



ça c'est bon !


Je suis sensibilisé à pas mal de problèmes et de méthodes de prog mais je ne
pensais pas que l'appel de proc "inter-bases" pouvais consommer autant de
ressources.

Mon appli nécéssite très certainement un grand ménage; voir même un
redeveloppement en parrallèle de l'appli en prod... mais là c'est une
question de cout/homme.
Cela fait plus de 2 ans qu'on lui colle des "rustines" toujours en
urgence... Nos commerciaux vendent des fonctionalités avant même qu'elles
existent ! D'ou une certaine pression au service info :-(

Mais là c'est un autre débat politico-commercialo-marketingo-managerio ! Ce
n'est pas moi le boss ... (qui sait un jour peut-être ;-) )




oui, le jour ou un client pétera les plombs !



Quel est le volume de tes bases ?



Environs 12 Go toutes rassemblées



c'est correct, dans les bases de taille moyenne.
Décrit moi ton serveur (PC) et le nombre des user.
Je suppose qu'en rassemblant les bases tu va éviter un peu de redondance ?




Serveur de prod :
Bi-Xéon 2,4GHZ en Hyper Threading 2Go RAM 2 Espace RAID 5 de 100 Go (Carte
Raid PROMISE SX6000 ): Un pour les bases, un autre pour les journaux de
transac et quelque archivages de fichiers.
Le système (W2K Server) est installé sur un 7eme disque IDE classique de 50
Go



pas mal. Tu pourrais obtenir des perf en plus avec : plus de RAM et AWE, mais
surtout, quoique coûteux, plus de disques et une organisation RAID 0 et RAID 0+1
(ou RAID 10).


Serveur de dev : (celui sur lequel j'ai eu mes messages d'erreurs)
Mono P4 2,4GHZ 768 Mo RAM 1 seul espace RAID 5 de 40 Go

Etant donné que l'appli est un extranet pour nos clients le nombre de
connexion est variable mais il dépasse rarement les 50 simultanées.

Avant cette appli j'en ai fait une autre qui fonctionne, depuis 3 ans (sans
problème) avec une seule base et qui brasse de gros volume d'info.
Elle importe via des lot DTS des tickets d'info (environs 100 par secondes)
ce qui me génére entre 40 et 60 Go de données par mois. mais là j'ai été
obligé de découpé en plusieur FILEGROUP et je ne garde que les 3 derniers
mois glissants.



Parfait : découper la base en plusieurs files groups et les répartir sur des
disques physiques pour paralléliser les accès !


Pour l'extranet j'ai changé de méthode et découpé en plusieurs bases dans un
soucis de clarté, pensant bien faire ... no comment ;-)



hélas !


Encore merci Fred de ta contribution à ce newsgroup qui permet à plusieurs
d'entre nous de se sortir de mauvaise passe ou de se défaire de mauvaise
habitude ... meme si, parfois, il ne faut pas être trop suceptible :-))



Susceptible, non... Mais féroce ! ;-)

A +


@+






@+





A +



@+



"Fred BROUARD" a écrit dans le message de
news:



a écrit:



Je n'ai pas de requete faisant intervenir plusieurs bases, j'en ai





quelques



unes faisant intervenir plusieur tables (et encore, moins de 8) .

Par contre je fait appel à des procédures qui appel d'autre proc qui





elles



mêmes en appelles d'autre etc ... peut-être au delà de 8 niveaux et









dans


3



bases différentes maximum sur un meme serveur.

cela pourrait t'il etre la cause du message ?




He oui, cela s'apelle la programmation spaghetti !

Même avec trois bases, il peut voir 8 appels successifs d'une base à



l'autre.



Exemple :

Base A, Procedure A1 appel => Base B, Procédure B1 => Base A procedure







A2


pour lui, c'est 3 bases ouvertes qu'il faut maintenir avec chacune











leur

espace



de travail.

Non seulement c'est du spaghetti, mais le meilleur moyen de bouffer







toute


la RAM



pour rien et faire un veau applicatif !

A +



"Fred BROUARD" a écrit dans le message de
news:




C'est assez clair : SQL Server admet que l'on travaille avec jusqu'à















8

bases de




donnés différentes dans une même requête. Apparament ce max a été







dépassé



!




A +

Francky a écrit:




Bonjour,

Au cours du déroulement du proc un peu complexe j'obtiens
ce message d'erreur.
Ma proc se termine quand même comme il faut.
Je ne comprends pas le sens de ce message ...

Serveur : Msg 925, Niveau 19, État 1, Ligne 1
Le nombre maximal de bases de données utilisées dans
chaque requête a été dépassé. Le maximum autorisé est 8.

merci d'avance pour votre aide.





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi,















web

Livre SQL - col. Référence :















http://sqlpro.developpez.com/bookSQL.html

Le site du SQL, pour débutants et pros :















http://sqlpro.developpez.com

************************ www.datasapiens.com















*************************





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************








--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************








--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************









--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
1 2