je suis un peu dans le même cas que jaunit
dans "Message-ID:<eqc7bj$gl0$1@aioe.org>".
bref une bille .....
en gros,j'ai d'un côté un logiciel (asterisk) qui va faire
des requétes SQL précises dans une table precise.
de l'autre,je trouve que pour le gérer ,ce n'est pas souple.
exemple:
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
dwojylac.nospam
Eric Stern wrote:
bonsoir tout le monde
je suis un peu dans le même cas que jaunit dans "Message-ID:<eqc7bj$gl0$". bref une bille .....
en gros,j'ai d'un côté un logiciel (asterisk) qui va faire des requétes SQL précises dans une table precise. de l'autre,je trouve que pour le gérer ,ce n'est pas souple. exemple:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
il faut dans ce cas rejouter un champ id_sip à la table entité qui contiendra la valeur de l'id de l'élément sip de rattachement.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
je suis un peu dans le même cas que jaunit dans "Message-ID:<eqc7bj$gl0$". bref une bille .....
lire la réponse de Fred Brouard à ce post que tu cites
lire aussi http://sql.developpez.com/sqlaz/jointures/ et d'une façon plus générale : http://sql.developpez.com/
Mais avant de se lancer, un petit travail crayon / papier sur la structure des données et ce que l'on veut faire est un temps qui n'est largement pas perdu.
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
-- http://wojylac.free.fr Un proverbe chinois dit que lorsqu'on a rien à dire on cite généralement un proverbe chinois.
Eric Stern <xdv5@ragnarok.frmug.org> wrote:
bonsoir tout le monde
je suis un peu dans le même cas que jaunit
dans "Message-ID:<eqc7bj$gl0$1@aioe.org>".
bref une bille .....
en gros,j'ai d'un côté un logiciel (asterisk) qui va faire
des requétes SQL précises dans une table precise.
de l'autre,je trouve que pour le gérer ,ce n'est pas souple.
exemple:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont
reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où
l'inverse.
il faut dans ce cas rejouter un champ id_sip à la table entité qui
contiendra la valeur de l'id de l'élément sip de rattachement.
Pour les requètes dans ce cas il faut utiliser les jointures
select * from entite E join sip S on E.id_sip = S.id where ....
je suis un peu dans le même cas que jaunit
dans "Message-ID:<eqc7bj$gl0$1@aioe.org>".
bref une bille .....
lire la réponse de Fred Brouard à ce post que tu cites
lire aussi
http://sql.developpez.com/sqlaz/jointures/
et d'une façon plus générale :
http://sql.developpez.com/
Mais avant de se lancer, un petit travail crayon / papier sur la
structure des données et ce que l'on veut faire est un temps qui n'est
largement pas perdu.
Petite remqrque : perso j'éviterais de mettre des caractères accentués
dans les noms des tables et des champs (on sait jamais)
--
http://wojylac.free.fr
Un proverbe chinois dit que lorsqu'on a rien à dire
on cite généralement un proverbe chinois.
je suis un peu dans le même cas que jaunit dans "Message-ID:<eqc7bj$gl0$". bref une bille .....
en gros,j'ai d'un côté un logiciel (asterisk) qui va faire des requétes SQL précises dans une table precise. de l'autre,je trouve que pour le gérer ,ce n'est pas souple. exemple:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
il faut dans ce cas rejouter un champ id_sip à la table entité qui contiendra la valeur de l'id de l'élément sip de rattachement.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
je suis un peu dans le même cas que jaunit dans "Message-ID:<eqc7bj$gl0$". bref une bille .....
lire la réponse de Fred Brouard à ce post que tu cites
lire aussi http://sql.developpez.com/sqlaz/jointures/ et d'une façon plus générale : http://sql.developpez.com/
Mais avant de se lancer, un petit travail crayon / papier sur la structure des données et ce que l'on veut faire est un temps qui n'est largement pas perdu.
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
-- http://wojylac.free.fr Un proverbe chinois dit que lorsqu'on a rien à dire on cite généralement un proverbe chinois.
Eric Stern
Dominique disait:
Eric Stern wrote:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
au final,c'est ce que je veux obtenir ..... en gros,dans un commutateur téléphonique commercial,un utilisateur est catalogué par un ensemble de paramètre regroupé par famille. typiquement la discrimination: il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale" plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
excellente suggestion ;)
Eric
Dominique disait:
Eric Stern <xdv5@ragnarok.frmug.org> wrote:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont
reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où
l'inverse.
au final,c'est ce que je veux obtenir .....
en gros,dans un commutateur téléphonique commercial,un utilisateur est
catalogué par un ensemble de paramètre regroupé par famille.
typiquement la discrimination:
il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale"
plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures
select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête
effectué par l'appli.
une procédure peut-elle être embarquée dans une table ?.
dans le genre:
CREATE TABLE `sip` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(80) NOT NULL default '',
`ailleurs select * from entite WHERE name=national
)
Petite remqrque : perso j'éviterais de mettre des caractères accentués
dans les noms des tables et des champs (on sait jamais)
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
au final,c'est ce que je veux obtenir ..... en gros,dans un commutateur téléphonique commercial,un utilisateur est catalogué par un ensemble de paramètre regroupé par famille. typiquement la discrimination: il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale" plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
excellente suggestion ;)
Eric
William Marie
"Dominique" a écrit dans le message de news: 1htqkw2.67mhw1qfhiyoN%
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai voulu passer des tables Access sur MS SQL Server avec des noms de champs accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
"Dominique" <dwojylac.nospam@free.fr.invalid> a écrit dans le message de
news: 1htqkw2.67mhw1qfhiyoN%dwojylac.nospam@free.fr.invalid...
Petite remqrque : perso j'éviterais de mettre des caractères accentués
dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai
voulu passer des tables Access sur MS SQL Server avec des noms de champs
accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser
mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a
horreur des noms de projets/solutions accentués ou à rallonge. Il vous
balancera des erreurs assembly alors que vous avez juste fait un petit truc
tout simple.
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
"Dominique" a écrit dans le message de news: 1htqkw2.67mhw1qfhiyoN%
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai voulu passer des tables Access sur MS SQL Server avec des noms de champs accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
dwojylac.nospam
Eric Stern wrote:
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Je ne pense pas. Si tu n'as pas la main sur les requètes, cela ne me semble pas possible de mettre une requete dans un champ, champ qui serait automatiquement interprété comme à exécuter, sans autre intervention que cette première requète.
-- http://wojylac.free.fr Un proverbe chinois dit que lorsqu'on a rien à dire on cite généralement un proverbe chinois.
Eric Stern <xdv5@ragnarok.frmug.org> wrote:
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête
effectué par l'appli.
une procédure peut-elle être embarquée dans une table ?.
dans le genre:
CREATE TABLE `sip` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(80) NOT NULL default '',
`ailleurs select * from entite WHERE name=national
)
Je ne pense pas. Si tu n'as pas la main sur les requètes, cela ne me
semble pas possible de mettre une requete dans un champ, champ qui
serait automatiquement interprété comme à exécuter, sans autre
intervention que cette première requète.
--
http://wojylac.free.fr
Un proverbe chinois dit que lorsqu'on a rien à dire
on cite généralement un proverbe chinois.
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Je ne pense pas. Si tu n'as pas la main sur les requètes, cela ne me semble pas possible de mettre une requete dans un champ, champ qui serait automatiquement interprété comme à exécuter, sans autre intervention que cette première requète.
-- http://wojylac.free.fr Un proverbe chinois dit que lorsqu'on a rien à dire on cite généralement un proverbe chinois.
ALain Montfranc
Eric Stern a écrit
Dominique disait:
Eric Stern wrote:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
au final,c'est ce que je veux obtenir ..... en gros,dans un commutateur téléphonique commercial,un utilisateur est catalogué par un ensemble de paramètre regroupé par famille. typiquement la discrimination: il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale" plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Non mais tu peux creer des vues ou des triggers
Eric Stern a écrit
Dominique disait:
Eric Stern <xdv5@ragnarok.frmug.org> wrote:
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont
reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où
l'inverse.
au final,c'est ce que je veux obtenir .....
en gros,dans un commutateur téléphonique commercial,un utilisateur est
catalogué par un ensemble de paramètre regroupé par famille.
typiquement la discrimination:
il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale"
plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures
select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête
effectué par l'appli.
une procédure peut-elle être embarquée dans une table ?.
dans le genre:
CREATE TABLE `sip` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(80) NOT NULL default '',
`ailleurs select * from entite WHERE name=national
)
Cela n'a d'intéret de créer deux tables que si à 1 élément "sip" sont reliés plusieurs éléments "entité" (1 à n mais en général n>1) - où l'inverse.
au final,c'est ce que je veux obtenir ..... en gros,dans un commutateur téléphonique commercial,un utilisateur est catalogué par un ensemble de paramètre regroupé par famille. typiquement la discrimination: il est plus simple de dire au Pabx qu'un usager est de categorie "Nationale" plutôt que d'énumerer à chaque fois les numéros auquel il a droit.
Pour les requètes dans ce cas il faut utiliser les jointures select * from entite E join sip S on E.id_sip = S.id where ....
c'est là ou le bat blesse,c'est que je n'ai pas la main sur la requête effectué par l'appli. une procédure peut-elle être embarquée dans une table ?. dans le genre:
CREATE TABLE `sip` ( `id` int(11) NOT NULL auto_increment, `name` varchar(80) NOT NULL default '', `ailleurs select * from entite WHERE name=national )
Non mais tu peux creer des vues ou des triggers
William Marie
"William Marie" a écrit dans le message de news: 45d88e8b$0$4440$
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple.
Précisions : en fait ça doit être l'apostrophe qui pose problème (célèbre gag bien connu des SGBDistes). par exemple essayez de créer un projet sous Visual C# 2005 appelé "Visionneuse d'images" et essayez de le compiler (pas nécessaire d'en écrire une ligne, juste avec le formulaire par défaut). Vous vous faites jeter. Le plus amusant est que le même nom de projet sous Visual C# 2003 passe très bien.
Donc prudence et même sous Windows soyez unixiens dans vos noms : pas de minuscules accentuées, pas d'espace (mais_des_traits_de_jonctions) et ResPecTeZ la casse okazou. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
"William Marie" <wmarie@trapellun.invalid> a écrit dans le message de news:
45d88e8b$0$4440$426a74cc@news.free.fr...
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005
a horreur des noms de projets/solutions accentués ou à rallonge. Il vous
balancera des erreurs assembly alors que vous avez juste fait un petit
truc tout simple.
Précisions : en fait ça doit être l'apostrophe qui pose problème (célèbre
gag bien connu des SGBDistes). par exemple essayez de créer un projet sous
Visual C# 2005 appelé "Visionneuse d'images" et essayez de le compiler (pas
nécessaire d'en écrire une ligne, juste avec le formulaire par défaut). Vous
vous faites jeter. Le plus amusant est que le même nom de projet sous Visual
C# 2003 passe très bien.
Donc prudence et même sous Windows soyez unixiens dans vos noms : pas de
minuscules accentuées, pas d'espace (mais_des_traits_de_jonctions) et
ResPecTeZ la casse okazou.
--
=================================== William Marie
Attention antiSpam remplacer trapellun.invalid
par free.fr
Web : http://wmarie.free.fr
http://www.pandemonium.dnsalias.org (site expérimental)
====================================
"William Marie" a écrit dans le message de news: 45d88e8b$0$4440$
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple.
Précisions : en fait ça doit être l'apostrophe qui pose problème (célèbre gag bien connu des SGBDistes). par exemple essayez de créer un projet sous Visual C# 2005 appelé "Visionneuse d'images" et essayez de le compiler (pas nécessaire d'en écrire une ligne, juste avec le formulaire par défaut). Vous vous faites jeter. Le plus amusant est que le même nom de projet sous Visual C# 2003 passe très bien.
Donc prudence et même sous Windows soyez unixiens dans vos noms : pas de minuscules accentuées, pas d'espace (mais_des_traits_de_jonctions) et ResPecTeZ la casse okazou. -- =================================== William Marie Attention antiSpam remplacer trapellun.invalid par free.fr Web : http://wmarie.free.fr http://www.pandemonium.dnsalias.org (site expérimental) ====================================
Eric Stern
ALain Montfranc disait:
Non mais tu peux creer des vues ou des triggers
c'est cool ça ;) il reste à voir si je peux reussir à utiliser tout ça.
merci
Eric
ALain Montfranc disait:
Non mais tu peux creer des vues ou des triggers
c'est cool ça ;) il reste à voir si je peux reussir à utiliser tout ça.
c'est cool ça ;) il reste à voir si je peux reussir à utiliser tout ça.
merci
Eric
Fred Brouard - SQLpro
William Marie a écrit :
"Dominique" a écrit dans le message de news: 1htqkw2.67mhw1qfhiyoN%
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai voulu passer des tables Access sur MS SQL Server avec des noms de champs accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple.
C'est parfaitement normal, car SQL est un langage normatif et les noms des objets doivent être codifié en respectant la norme, c'est à dire : 1) n'utiliser que les 26 lettres + 10 chiffres et le blanc souligné à l'exception de tout autre caractère 2) commencer par une lettre 3) comporter au maximum 128 caractères.
Hélas un certains nombre de SGBDr ne respecte pas la norme à commencer par Access ou SQL Server... (tiens, deux produits MS!!! ;-)
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
William Marie a écrit :
"Dominique" <dwojylac.nospam@free.fr.invalid> a écrit dans le message de
news: 1htqkw2.67mhw1qfhiyoN%dwojylac.nospam@free.fr.invalid...
Petite remqrque : perso j'éviterais de mettre des caractères accentués
dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai
voulu passer des tables Access sur MS SQL Server avec des noms de champs
accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser
mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a
horreur des noms de projets/solutions accentués ou à rallonge. Il vous
balancera des erreurs assembly alors que vous avez juste fait un petit truc
tout simple.
C'est parfaitement normal, car SQL est un langage normatif et les noms
des objets doivent être codifié en respectant la norme, c'est à dire :
1) n'utiliser que les 26 lettres + 10 chiffres et le blanc souligné à
l'exception de tout autre caractère
2) commencer par une lettre
3) comporter au maximum 128 caractères.
Hélas un certains nombre de SGBDr ne respecte pas la norme à commencer
par Access ou SQL Server... (tiens, deux produits MS!!! ;-)
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
"Dominique" a écrit dans le message de news: 1htqkw2.67mhw1qfhiyoN%
Petite remqrque : perso j'éviterais de mettre des caractères accentués dans les noms des tables et des champs (on sait jamais)
Pour les exportations, à coup sûr, on a des ennuis. Par exemple j'ai voulu passer des tables Access sur MS SQL Server avec des noms de champs accentués comme "Désignation", la moulinette se bloquait, j'ai du ASCIIiser mes tables Access avant d'espérer faire quelque chose.
A savoir aussi (hors SGBD, mais si ça peut servir) : Visual Studio 2005 a horreur des noms de projets/solutions accentués ou à rallonge. Il vous balancera des erreurs assembly alors que vous avez juste fait un petit truc tout simple.
C'est parfaitement normal, car SQL est un langage normatif et les noms des objets doivent être codifié en respectant la norme, c'est à dire : 1) n'utiliser que les 26 lettres + 10 chiffres et le blanc souligné à l'exception de tout autre caractère 2) commencer par une lettre 3) comporter au maximum 128 caractères.
Hélas un certains nombre de SGBDr ne respecte pas la norme à commencer par Access ou SQL Server... (tiens, deux produits MS!!! ;-)
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
