Discussion :

[draidius]

Bonjour

J'ai fait un tableau PHP qui va aller chercher des données dans une base SLQ express

Je peux ajouter des nouvelles lignes et supprimer la dernière ligne sans problème via un formulaire php et son fichier de traitement.
Par contre je n'arrive pas à faire des insertions ou des suppressions sans que ne pose de problème dans la base car ce sont des ID auto incrémenté.

et même via un script purement SQL, cela me donne en suppression un trou dans les ID et quand je veux remettre une ligne cela me met un message d’erreur " violation **** " il faut désactiver un truc et le réactiver un après, d'autant que si je veux modifier la ligne par exemple 25, en réalité il faut indiquer l'ID 24...

Je ne sais pas si il y a déjà des scripts tous fait ou non pour résoudre mes deux problèmes, si c'est le cas, je suis preneur

exemple code SQL ligne 104 pour remettre une ligne supprimé

SET IDENTITY_INSERT AttributionAbon ON;

INSERT INTO AttributionAbon (ID, Departutil, NomUtilisateur, NomOrdinateur, EnvSystem, NomLogiciel, VersLogiciel, NumBC, NumDeSerie, CleLicence, TypeIns, InfoActivation, DateFinAbon, NumTicket, Commentaire)
VALUES (104, 'Test', 'toto', 'pc01', 'Windows', 'test', '1', '001', 'test', '123456', 'Initial', 'N/A', '02022022', 'TCK0001', 'RAS');

SET IDENTITY_INSERT AttributionAbon OFF;

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Merci d'avance

[Séb.]

je n'arrive pas à faire des insertions ou des suppressions sans que ne pose de problème dans la base car ce sont des ID auto incrémenté.
et même via un script purement SQL, cela me donne en suppression un trou dans les ID

Un ID ne doit être utilisé qu'une seule et unique fois. Une suppression provoque donc un trou, c'est normal.

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Il ne faut surtout pas faire cela. Résultat de telles pratiques avec un cas classique :

1. Chargement de la ligne ID 123 pour modification
2. Suppression de la ligne ID 100
3. Modification de l'ID des lignes 101 et plus en ID − 1 => La ligne ID 123 devient ID 122, la ligne ID 124 devient ID 123
4. L'utilisateur qui était en train d'éditer la ligne initialement ID 123 soumet ses modifications => Les modifs sont enregistrées et écrasent les valeurs de la ligne initialement ID 124

[draidius]

Bonjour Séb

Ok donc pour le visuel, il faut que j'adapte le code pour ne pas avoir de trou dans le tableau visible par l'utilisateur...

ça promet quelques de travail ( enfin heure pour moi .. )


Merci pour ta réponse..
donc après pour les insertions les lignes vont se suivre dans la base SQL mais ce sera le n° dans le tableau PHP qui vont changer....

[laurentSc]

Bonsoir draidius,
as-tu encore une erreur SQL quand tu insères une ligne (sans insérer l'ID vu que c'est auto-incrémenté) ?

[Séb.]

Ok donc pour le visuel, il faut que j'adapte le code pour ne pas avoir de trou dans le tableau visible par l'utilisateur...
ça promet quelques de travail ( enfin heure pour moi .. )

S'il s'agit d'un index de ligne alors tu peux utiliser ROW_NUMBER() :

Code sql :

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

1
2
3
4
5
SELECT ALL
    id, created_at, col1, col2,
    ROW_NUMBER() OVER (ORDER BY created_at ASC) AS row_index
FROM your_table
ORDER BY created_at ASC

La colonne row_index vaudra 1 pour la 1re ligne, 2 pour la 2nde, etc. selon l'ordre de tri spécifié (ici selon l'horodatage de création) et en toute indépendance de l'ID.

[draidius]

...

Bonjour laurentSc
Oui, ppiur l'instant le problème est en suspens, j’étais passé à autre chose pour le moment mais je suis preneur de conseil...
Merci

...

Merci, je vais tester ça

[laurentSc]

Oui, ppiur l'instant le problème est en suspens, j’étais passé à autre chose pour le moment mais je suis preneur de conseil...
Merci

Dans ce cas, donne STP, la structure SQL de ta table (fais un export)

[escartefigue]

Bonjour draidius

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Ce serait non pas l'idéal, mais une très mauvaise chose : ce serait inutile et très couteux, notamment en raison de l'intégrité référentielle.

Cette question revient très fréquemment, c'est pourquoi je lui ai consacré un billet de blog, à lire attentivement

[draidius]

Dans ce cas, donne STP, la structure SQL de ta table (fais un export)

Bonjour laurent
Voici la structure:

Code sql :

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
USE [Base_Logiciel_Siege]
GO
/****** Object:  Table [dbo].[Attribution]    Script Date: 15/05/2024 13:37:23 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Attribution](
	[ID] [int] IDENTITY(1,1) NOT NULL,
	[nomDepartement] [nvarchar](255) NULL,
	[NomUtilisateur] [nvarchar](255) NULL,
	[NomOrdinateur] [nvarchar](255) NULL,
	[SerialAPPL] [nvarchar](255) NULL,
	[NomLogiciel] [nvarchar](255) NULL,
	[VersionLogiciel] [nvarchar](255) NULL,
	[CleLicence] [nvarchar](255) NULL,
	[EnvSystem] [nvarchar](255) NULL,
	[NumTicket] [nvarchar](255) NULL,
	[DateMAJ] [date] NULL,
	[Verification] [nvarchar](255) NULL,
	[Commentaire] [nvarchar](max) NULL,
PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

[laurentSc]

Il ne faut surtout pas faire cela

Ce serait non pas l'idéal, mais une très mauvaise chose

Vu les remarques qui t'ont été faites, il ne faut pas chercher à modifier les IDs...

[escartefigue]

Cette table est modélisée avec les pieds

CREATE TABLE [dbo].[Attribution](
[ID] [int] IDENTITY(1,1) NOT NULL,
[nomDepartement] [nvarchar](255) NULL,
[NomUtilisateur] [nvarchar](255) NULL,
[NomOrdinateur] [nvarchar](255) NULL,
[SerialAPPL] [nvarchar](255) NULL,
[NomLogiciel] [nvarchar](255) NULL,
[VersionLogiciel] [nvarchar](255) NULL,
[CleLicence] [nvarchar](255) NULL,
[EnvSystem] [nvarchar](255) NULL,
[NumTicket] [nvarchar](255) NULL,
[DateMAJ] [date] NULL,
[Verification] [nvarchar](255) NULL,
[Commentaire] [nvarchar](max) NULL,
PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO[/CODE]

• Toutes les colonnes sont "nullables", alors que les colonnes "nullables" devraient être l'exception, en l'état, vous pouvez enregistrer une ligne avec seulement un identifiant et rien d'autre
• Quasiment toutes les colonnes sont de type nvarchar(255), autrement dit, dimensionnées au pif sans tenir compte du réel besoin
• Pour un même identifiant, on trouve un nom d'utilisateur, un nom d'équipement, un nom de département, bref, tout un tas d'attributs qui devraient être remplacés par des clefs étrangères faisant référence à la table des utilisateur, à la table des équipements, des départements...
  Ce faisant, si un même utilisateur a plusieurs ordinateurs, il faudra créer autant de lignes, avec des risques d'orthographies différentes et donc de confusion, de plus, comme c'est le nom qui est stocké au lieu de son identifiant, si plusieurs utilisateurs s'appellent "dupond", on ne saura jamais duquel il s'agit

Il existe un forum consacré à la modélisation, il se trouve ICI
Je vous recommande chaudement d'y exposer votre besoin, car une base de donnée mal modélisée est la source de données non fiables et non intègres, de requêtes complexes et de performances désastreuses.