Discussion :

[Krapo_Lazer]

Bonsoir à tous,

Contexte Technique:
je suis chargé de l'administration à distance d'une base de données MS SQL Server 2005. Le développeur d'origine a créé une interface MS Access pour interagir avec cette base de données.
Le serveur tourne sous Small Business Server 2003 R2. Nous utilisons Office 2003 sur les postes du réseau.

Contexte utilisateur
Je ne suis nullement compétent en la matière et suis en charge de cette base par la force des choses. Ma compréhension des FAQ et des autres sujets des différents forums reste donc très limitée, même si ceux-ci m'ont déjà tiré de bien mauvais pas. Pour ceux qui auront la gentillesse de répondre, considérez que je suis un parfait débutant et que le jargon technique m'est inconnu et parfaitement abscons.
N'hésitez pas à préciser même ce qui vous paraît évident a priori.

Le problème
Je dois insérer des données tarifaires dans une table de ma base en utilisant mon interface Access. Je réalisais cette opération 2 fois l'an sans problème particulier. Cette fois-ci, Voici le message que me retourne SQL:

ODBC -- l'appel a échoué.

[Microsoft][ODBC SQL Server Driver][SQL Server]Violation de la contrainte PRIMARY KEY 'PK_TTarifs'. Impossible d'insérer une clé en double dans l'objet 'dbo.TTarifs'.(#2627)

Je suis allé comme à l'accoutumée trainer mes guêtres du côté des FAQ et j'ai trouvé cette ligne de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select IDENT_CURRENT('TTarifs')

qui m'a permis de savoir à combien l'incrémentation automatique de la clé primaire de cette table s'est arrêtée. Celle-ci s'est arrêtée à 11511 alors que la valeur la plus haute que je constate visuellement dans ma table est 11940.

J'ai vu une autre ligne de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKIDENT ('MaTable', RESEED, 1)

qui devrait me permettre de réinitialiser l'incrémentation et ici se trouve le cœur de mon interrogation:

Si j'utilise cette requête, puis-je relancer l'incrémentation à 11941 en remplaçant le 1 par 11941 ?

J'aimerai avoir confirmation que cela ne vidangera pas ma table de ses données actuelles mais que cela ne fera que redémarrer l'incrémentation automatique au point que je lui indique.

Pour Info

La base s'appelle MEDIARIS. La table TTarifs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
USE [MEDIARIS]
GO
/****** Objet :  Table [dbo].[TTarifs]    Date de génération du script : 06/12/2008 17:34:06 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[TTarifs](
	[Numéro] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	[NumMedia] [int] NOT NULL,
	[NumJour] [tinyint] NULL,
	[NumEmplacement] [int] NULL,
	[NumPage] [int] NOT NULL,
	[Format en mm] [int] NULL,
	[Format en col] [int] NULL,
	[mm_col] [int] NULL,
	[BorneInf] [smallint] NULL,
	[BorneSup] [smallint] NULL,
	[NumFormat] [int] NULL,
	[Numcouleurs] [int] NULL,
	[NumCouplage] [int] NULL,
	[Dégressif] [int] NULL,
	[Tarif forfaitaire en €] [float] NULL,
	[Tarif en € du mm_colonne] [float] NULL,
	[Tarif forfaitaire mensuel en €] [float] NULL,
	[DDébut] [smalldatetime] NULL,
	[DFin] [smalldatetime] NULL,
 CONSTRAINT [PK_TTarifs] PRIMARY KEY CLUSTERED 
(
	[Numéro] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
 
GO
ALTER TABLE [dbo].[TTarifs]  WITH NOCHECK ADD  CONSTRAINT [FK_TTarifs_TMedias] FOREIGN KEY([NumMedia])
REFERENCES [dbo].[TMedias] ([NumMedia])
NOT FOR REPLICATION 
GO
ALTER TABLE [dbo].[TTarifs] CHECK CONSTRAINT [FK_TTarifs_TMedias]

Je remercie par avance les membres de ce forum pour leur aide toujours précieuse et j'en profite pour les féliciter pour ce travail qui quotidiennement sauve les néophites complets d'une panade indescriptible.

Sincères Salutations.

KrapLaz

[Jinroh77]

Le principe d'une clef primaire avec une valeur en auto incrément est de ne pas se soucier des valeurs qui sont insérées dans ce champ.
Visiblement le script d'insertion dans cette table semble essayer de rentrer manuellement une valeur qui existe déjà. Or il ne devrait pas spécifier de valeur et laisser faire le moteur pour choisir celle-ci et, au besoin, la récupérer après insertion.

[SQLpro]

Effectivement nous ne savons pas si le script force l'auto incrément ou se repose dessus pour le calculs des clefs.

Bien entendu vous pouvez réinitialisé la graine, mais faites le avec une valeur beaucoup plus forte, car si quelqu'un entre temps rentre une nouvelle valeur vous incrément ne fonctionnera plus du tout. Ce n'est pas grave d'avoir des trous dans une numérotation. Donc repartez de 1000000 par exemple. (ça monte jusqu'à 4 milliards...)

Petite chose très déconvenante... Pas grave dans l'immédiat, mais qui risque de vous causer des soucis dans le futur si vous interfacez votre base : le non respect des noms des colonnes des tables. En effet un nom d'objet SQL doit impérativement se contenter des 26 lettres de l'alphabet (sans accents), des 10 chiffres et du blanc souligné ( _ ) tout autre caractères étant en principe interdit. Sauf que dans SQL Server il est possible d'outrepasser cette règle, mais vous risquez que certains outils tiers ne fonctionnent pas avec votre base...

A +

[Krapo_Lazer]

Je vous remercie pour vos réponses. Je vais donc tenter l'expérience.

J'ai été alerté sur ces violations des conventions de nommage dans plusieurs colonnes des tables composant la base.
Il est en effet impossible de mettre cette base en réplication sans provoquer de problèmes multiples. L'un de nos prestataires assisté par l'un de vos spécialistes en Delphi (Sylvain), en a fait la triste expérience. Une semaine de test concluant puis 3 mois de mise en production réelle avant que la base ne se pare de doublons et aberrations inexplicables=Roll back.

La base ayant été entièrement conçue dans cet esprit, toute modification semble suicidaire. En l'absence de commentaires, il faudrait en dérouler tout le code pour savoir comment elle a été conçue. Autant tout faire redévelopper, ce à quoi je m'attellerai dès que possible.

Merci en tout cas de me l'avoir signalé.

Bonne continuation.

K.

[Jinroh77]

A moins que je n'ai pas tout compris, mais l'utilisation des clefs primaire et le fait d'avoir ce genre de contrainte n'est pas une mauvaise chose.
La base n'est pas à modifier sur ce point, par contre ce sont les scripts d'insertion ou autre, de la base Access qu'il faudrait revoir.