Bonjour
J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select
IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au
client ayant fait la réclamation. Il arrive que deux opératrices fournissent
le même numéro a deux clients différents. Je ne sais pas si les gens
comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler ce
conflit d'accès.
Par exemple : Créez l'enr. avant de fournir le numéro, quitte à venir le supprimer ensuite et à gérer spécifiquement les numéros non affectés
Patrice Scribe
Cette fonction donne le dernier numéro créé (par qui et quand que ce soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" a écrit dans le message de news:
Bonjour J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au client ayant fait la réclamation. Il arrive que deux opératrices
fournissent
le même numéro a deux clients différents. Je ne sais pas si les gens comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler ce conflit d'accès.
Merci d'avance
Cette fonction donne le dernier numéro créé (par qui et quand que ce soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement
crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" <modiop@hotmail.com> a écrit dans le message de
news:uC9AwdU9DHA.1428@TK2MSFTNGP12.phx.gbl...
Bonjour
J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select
IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au
client ayant fait la réclamation. Il arrive que deux opératrices
fournissent
le même numéro a deux clients différents. Je ne sais pas si les gens
comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler ce
conflit d'accès.
Cette fonction donne le dernier numéro créé (par qui et quand que ce soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" a écrit dans le message de news:
Bonjour J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au client ayant fait la réclamation. Il arrive que deux opératrices
fournissent
le même numéro a deux clients différents. Je ne sais pas si les gens comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler ce conflit d'accès.
Merci d'avance
JOE DALTON
Merci à vous Je vais voir ça
"Patrice Scribe" a écrit dans le message de news:
Cette fonction donne le dernier numéro créé (par qui et quand que ce
soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" a écrit dans le message de news: > Bonjour > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au > client ayant fait la réclamation. Il arrive que deux opératrices fournissent > le même numéro a deux clients différents. Je ne sais pas si les gens > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler
ce
> conflit d'accès. > > Merci d'avance > >
Merci à vous
Je vais voir ça
"Patrice Scribe" <nobody@nowhere.com> a écrit dans le message de
news:eJulXKV9DHA.3024@TK2MSFTNGP09.phx.gbl...
Cette fonction donne le dernier numéro créé (par qui et quand que ce
soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement
crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" <modiop@hotmail.com> a écrit dans le message de
news:uC9AwdU9DHA.1428@TK2MSFTNGP12.phx.gbl...
> Bonjour
> J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select
> IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au
> client ayant fait la réclamation. Il arrive que deux opératrices
fournissent
> le même numéro a deux clients différents. Je ne sais pas si les gens
> comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler
Cette fonction donne le dernier numéro créé (par qui et quand que ce
soit).
Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
"JOE DALTON" a écrit dans le message de news: > Bonjour > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au > client ayant fait la réclamation. Il arrive que deux opératrices fournissent > le même numéro a deux clients différents. Je ne sais pas si les gens > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler
ce
> conflit d'accès. > > Merci d'avance > >
JOE DALTON
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news:
Merci à vous Je vais voir ça
"Patrice Scribe" a écrit dans le message de news: > Cette fonction donne le dernier numéro créé (par qui et quand que ce soit). > > Il faudrait plutôt donner le n° utilisé effectivement par
l'enregistrement
> crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > "JOE DALTON" a écrit dans le message de > news: > > Bonjour > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi
(select
> > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au > > client ayant fait la réclamation. Il arrive que deux opératrices > fournissent > > le même numéro a deux clients différents. Je ne sais pas si les gens > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de
Je crois que votre idée est la meilleure mais mon problème est comment
supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de
numéro).
"JOE DALTON" <modiop@ifrance.com> a écrit dans le message de
news:eUpI1NV9DHA.2432@TK2MSFTNGP09.phx.gbl...
Merci à vous
Je vais voir ça
"Patrice Scribe" <nobody@nowhere.com> a écrit dans le message de
news:eJulXKV9DHA.3024@TK2MSFTNGP09.phx.gbl...
> Cette fonction donne le dernier numéro créé (par qui et quand que ce
soit).
>
> Il faudrait plutôt donner le n° utilisé effectivement par
l'enregistrement
> crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
>
>
>
> "JOE DALTON" <modiop@hotmail.com> a écrit dans le message de
> news:uC9AwdU9DHA.1428@TK2MSFTNGP12.phx.gbl...
> > Bonjour
> > J'essaie de récupérer le prochaine numéro auto d'une table ainsi
(select
> > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au
> > client ayant fait la réclamation. Il arrive que deux opératrices
> fournissent
> > le même numéro a deux clients différents. Je ne sais pas si les gens
> > comprennent mon problème mais j'aimerai savoir s'il y a moyen de
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news:
Merci à vous Je vais voir ça
"Patrice Scribe" a écrit dans le message de news: > Cette fonction donne le dernier numéro créé (par qui et quand que ce soit). > > Il faudrait plutôt donner le n° utilisé effectivement par
l'enregistrement
> crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > "JOE DALTON" a écrit dans le message de > news: > > Bonjour > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi
(select
> > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit au > > client ayant fait la réclamation. Il arrive que deux opératrices > fournissent > > le même numéro a deux clients différents. Je ne sais pas si les gens > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de
DBCC CHECKIDENT avec l'option RESEED ? Compteur perso ? (voir le site de Fred http://sqlpro.developpez.com/ sur lequel tu devrais trouver une rubrique sur les compteurs perso). N° d'ordre calculé ?
Ceci dit, je ne vois pas pourquoi il y aurait des trous. Normalement les id sont générés consécutivement. Si tu détruis une réclamation, il me semble préférable de ne pas réutiliser son numéro plutôt que de chercher à le recycler (tu peux même ne détruire que logiquement l'enregistrement pour garder l'historique).
Patrice
--
"JOE DALTON" a écrit dans le message de news:%
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news: > Merci à vous > Je vais voir ça > > > "Patrice Scribe" a écrit dans le message de > news: > > Cette fonction donne le dernier numéro créé (par qui et quand que ce > soit). > > > > Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement > > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > > > > > "JOE DALTON" a écrit dans le message de > > news: > > > Bonjour > > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices > > fournissent > > > le même numéro a deux clients différents. Je ne sais pas si les gens > > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler > ce > > > conflit d'accès. > > > > > > Merci d'avance > > > > > > > > > >
DBCC CHECKIDENT avec l'option RESEED ?
Compteur perso ? (voir le site de Fred http://sqlpro.developpez.com/ sur
lequel tu devrais trouver une rubrique sur les compteurs perso).
N° d'ordre calculé ?
Ceci dit, je ne vois pas pourquoi il y aurait des trous. Normalement les id
sont générés consécutivement. Si tu détruis une réclamation, il me semble
préférable de ne pas réutiliser son numéro plutôt que de chercher à le
recycler (tu peux même ne détruire que logiquement l'enregistrement pour
garder l'historique).
Patrice
--
"JOE DALTON" <modiop@ifrance.com> a écrit dans le message de
news:%23bj2maV9DHA.1636@TK2MSFTNGP12.phx.gbl...
Je crois que votre idée est la meilleure mais mon problème est comment
supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de
numéro).
"JOE DALTON" <modiop@ifrance.com> a écrit dans le message de
news:eUpI1NV9DHA.2432@TK2MSFTNGP09.phx.gbl...
> Merci à vous
> Je vais voir ça
>
>
> "Patrice Scribe" <nobody@nowhere.com> a écrit dans le message de
> news:eJulXKV9DHA.3024@TK2MSFTNGP09.phx.gbl...
> > Cette fonction donne le dernier numéro créé (par qui et quand que ce
> soit).
> >
> > Il faudrait plutôt donner le n° utilisé effectivement par
l'enregistrement
> > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
> >
> >
> >
> > "JOE DALTON" <modiop@hotmail.com> a écrit dans le message de
> > news:uC9AwdU9DHA.1428@TK2MSFTNGP12.phx.gbl...
> > > Bonjour
> > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi
(select
> > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices
> > fournissent
> > > le même numéro a deux clients différents. Je ne sais pas si les gens
> > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de
régler
> ce
> > > conflit d'accès.
> > >
> > > Merci d'avance
> > >
> > >
> >
>
>
DBCC CHECKIDENT avec l'option RESEED ? Compteur perso ? (voir le site de Fred http://sqlpro.developpez.com/ sur lequel tu devrais trouver une rubrique sur les compteurs perso). N° d'ordre calculé ?
Ceci dit, je ne vois pas pourquoi il y aurait des trous. Normalement les id sont générés consécutivement. Si tu détruis une réclamation, il me semble préférable de ne pas réutiliser son numéro plutôt que de chercher à le recycler (tu peux même ne détruire que logiquement l'enregistrement pour garder l'historique).
Patrice
--
"JOE DALTON" a écrit dans le message de news:%
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news: > Merci à vous > Je vais voir ça > > > "Patrice Scribe" a écrit dans le message de > news: > > Cette fonction donne le dernier numéro créé (par qui et quand que ce > soit). > > > > Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement > > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > > > > > "JOE DALTON" a écrit dans le message de > > news: > > > Bonjour > > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices > > fournissent > > > le même numéro a deux clients différents. Je ne sais pas si les gens > > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler > ce > > > conflit d'accès. > > > > > > Merci d'avance > > > > > > > > > >
Fred BROUARD
JOE DALTON a écrit:
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
Dangereux et sans intérêt !!!
A lire : http://sqlpro.developpez.com/ClefsAuto/SQL_ClefsAuto.html
Imaginons qu'entre temps une sauvegarde se produise et enregistre la clef avant qu'elle ne soit détruite. Puis par soucis de comblement tu réattribue cette clef déjà périmée...
Que se passera t-il lors de la restauration de ta sauvegarde ???
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
A +
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / 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 ****************** mailto: ******************
JOE DALTON a écrit:
Je crois que votre idée est la meilleure mais mon problème est comment
supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de
numéro).
Dangereux et sans intérêt !!!
A lire :
http://sqlpro.developpez.com/ClefsAuto/SQL_ClefsAuto.html
Imaginons qu'entre temps une sauvegarde se produise et enregistre la
clef avant qu'elle ne soit détruite.
Puis par soucis de comblement tu réattribue cette clef déjà périmée...
Que se passera t-il lors de la restauration de ta sauvegarde ???
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
A +
--
Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / 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
****************** mailto:brouardf@club-internet.fr ******************
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
Dangereux et sans intérêt !!!
A lire : http://sqlpro.developpez.com/ClefsAuto/SQL_ClefsAuto.html
Imaginons qu'entre temps une sauvegarde se produise et enregistre la clef avant qu'elle ne soit détruite. Puis par soucis de comblement tu réattribue cette clef déjà périmée...
Que se passera t-il lors de la restauration de ta sauvegarde ???
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
A +
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / 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 ****************** mailto: ******************
JOE DALTON
Merci de tous ces conseils, je ne suis qu'un débutant.
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
J'accepte et se conforme à ce principe.
Merci à vous tous
"JOE DALTON" a écrit dans le message de news:%
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news: > Merci à vous > Je vais voir ça > > > "Patrice Scribe" a écrit dans le message de > news: > > Cette fonction donne le dernier numéro créé (par qui et quand que ce > soit). > > > > Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement > > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > > > > > "JOE DALTON" a écrit dans le message de > > news: > > > Bonjour > > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices > > fournissent > > > le même numéro a deux clients différents. Je ne sais pas si les gens > > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler > ce > > > conflit d'accès. > > > > > > Merci d'avance > > > > > > > > > >
Merci de tous ces conseils, je ne suis qu'un débutant.
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
J'accepte et se conforme à ce principe.
Merci à vous tous
"JOE DALTON" <modiop@ifrance.com> a écrit dans le message de
news:%23bj2maV9DHA.1636@TK2MSFTNGP12.phx.gbl...
Je crois que votre idée est la meilleure mais mon problème est comment
supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de
numéro).
"JOE DALTON" <modiop@ifrance.com> a écrit dans le message de
news:eUpI1NV9DHA.2432@TK2MSFTNGP09.phx.gbl...
> Merci à vous
> Je vais voir ça
>
>
> "Patrice Scribe" <nobody@nowhere.com> a écrit dans le message de
> news:eJulXKV9DHA.3024@TK2MSFTNGP09.phx.gbl...
> > Cette fonction donne le dernier numéro créé (par qui et quand que ce
> soit).
> >
> > Il faudrait plutôt donner le n° utilisé effectivement par
l'enregistrement
> > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY).
> >
> >
> >
> > "JOE DALTON" <modiop@hotmail.com> a écrit dans le message de
> > news:uC9AwdU9DHA.1428@TK2MSFTNGP12.phx.gbl...
> > > Bonjour
> > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi
(select
> > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices
> > fournissent
> > > le même numéro a deux clients différents. Je ne sais pas si les gens
> > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de
régler
> ce
> > > conflit d'accès.
> > >
> > > Merci d'avance
> > >
> > >
> >
>
>
Merci de tous ces conseils, je ne suis qu'un débutant.
Principe fondamental : toute clef consommée est DÉFINITIVEMENT PERDUE !
J'accepte et se conforme à ce principe.
Merci à vous tous
"JOE DALTON" a écrit dans le message de news:%
Je crois que votre idée est la meilleure mais mon problème est comment supprimer les numéros non utilisés pour qu'il ait pas de trou (saut de numéro).
"JOE DALTON" a écrit dans le message de news: > Merci à vous > Je vais voir ça > > > "Patrice Scribe" a écrit dans le message de > news: > > Cette fonction donne le dernier numéro créé (par qui et quand que ce > soit). > > > > Il faudrait plutôt donner le n° utilisé effectivement par l'enregistrement > > crée par l'opératrice (@@IDENTITY ou SCOPE_IDENTITY). > > > > > > > > "JOE DALTON" a écrit dans le message de > > news: > > > Bonjour > > > J'essaie de récupérer le prochaine numéro auto d'une table ainsi (select > > > IDENT_CURRENT ('RECLAMATIONS')). Ce numéro, l'opératrice le fournit
au
> > > client ayant fait la réclamation. Il arrive que deux opératrices > > fournissent > > > le même numéro a deux clients différents. Je ne sais pas si les gens > > > comprennent mon problème mais j'aimerai savoir s'il y a moyen de régler > ce > > > conflit d'accès. > > > > > > Merci d'avance > > > > > > > > > >
