Heidisql: AUTO_INCREMENT ne fonctionne pas sur le serveur MSSQL

Créé le 30 oct. 2018 · 5Commentaires · Source: HeidiSQL/HeidiSQL

Étapes pour reproduire ce problème

Créez une table sur un serveur SQL ;
Ajoutez une colonne ID ;
Définissez la colonne ID pour qu'elle s'incrémente automatiquement en définissant la valeur par défaut sur AUTO_INCREMENT ;
Enregistrez le tableau. Cela peut entraîner la création ou la mise à jour de la table. Cela échoue.

Comportement actuel

Il ne crée ni ne modifie la table.
Il donne une erreur sur la partie AUTO_INCREMENT de l'instruction.

Comportement attendu

Il doit créer ou mettre à jour la table.
Il ne devrait pas donner d'erreur.

Solution possible

Au lieu d'utiliser AUTO_INCREMENT, le serveur SQL requiert IDENTITY(1,1).
Le premier nombre entre parenthèses est la valeur de départ, le second est l'incrément.
Exemple:
CRÉER TABLE Personnes (
ID entier IDENTITY(1,1) CLÉ PRIMAIRE,
Nom varchar(255) NON NULL
);

Environnement

Version HeidiSQL :
9.5.0.5315, dernière version nocturne. En fait, je ne veux pas vraiment utiliser une version nocturne, mais une version stable.
Système et version de la base de données :
Serveur SQL, toutes versions.
Système opérateur:
Windows 10 sur client, inconnu sur serveur.

Source

jorisrobijn

👍3 👀1

Tous les 5 commentaires

Est-ce un grand changement ? Serait-ce facile pour un premier PR ?

reel le 9 déc. 2018

👍1

J'ai le même problème.
Y at-il une solution à ce problème?

it19862 le 18 févr. 2019

👍1

Oh mon Dieu! Nous sommes en 2020 et c'est toujours ouvert. S'il vous plaît guyz, corrigez ça dès que possible.
Pour info : j'utilise HeidiSql v10.3

ersuman le 1 janv. 2020

👍1

Courir aussi dans ce aujourd'hui. L'une des seules raisons pour lesquelles je dois ouvrir SSMS :(

garrynewman le 3 janv. 2020

Voici un script pour générer une table sur MS SQL 12.0.5223.6 qui illustre le problème :

CREATE TABLE [dbo].[User](
    [Username] [nvarchar](20) NOT NULL,
    [FullName] [nvarchar](50) NOT NULL,
    [EmailAddress] [nvarchar](100) NULL,
    [LastLoginDate] [datetime] NULL,
    [IsAdministrator] [bit] NULL,
    [Roles] [int] NOT NULL,
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [CreatedAt] [datetime2](7) NOT NULL,
    [CreatedBy] [nvarchar](20) NOT NULL,
    [ModifiedAt] [datetime2](7) NULL,
    [ModifiedBy] [nvarchar](20) NULL,
    [LastPortfolioId] [int] NULL,
 CONSTRAINT [PK__User__536C85E5B3CDBFE3] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[User] ADD  DEFAULT (getdate()) FOR [CreatedAt]
GO

ALTER TABLE [dbo].[User] ADD  DEFAULT (suser_sname()) FOR [CreatedBy]
GO

HeidiSQL 10.3.0.5838 ne détecte pas la clé primaire :

Voici un script qui sélectionne les index de clé primaire sur MS SQL (probablement pas les toutes premières versions de MS SQL) :

select schema_name(tab.schema_id) as [schema_name], 
    tab.[name] as table_name, 
    pk.[name] as pk_name,
    col.name as col_name
from 
  sys.tables tab
  left outer join sys.indexes pk on tab.object_id = pk.object_id and pk.is_primary_key = 1
  left join sys.index_columns ic on ic.index_id = pk.index_id and ic.object_id = tab.object_id
  inner join sys.columns col on ic.object_id = col.object_id and ic.column_id = col.column_id
order by schema_name(tab.schema_id),
    tab.[name]