Bonsoir,
Je dois faire migrer une grosse application de gestion.
Après conversion de la base access vers sql server, j'ai retrouvé les index
primaires déclarés selon le type de données INT
La plupart du temps j'ai du activer l'identité (spécification du compteur).
Le fonctionnement de l'application a fonctionné correctement sans trop de
bug...
Mais après un certain temps j'ai reçu des messages d'erreur de la part du
serveur en particulier lors d'instructions INSERT
(0 ligne(s) affectée(s))
Msg 8115, Niveau 16, État 1, Procédure sp_sql_copy_marché_for_client, Ligne
18
Une erreur de dépassement arithmétique s'est produite lors de la conversion
de IDENTITY en type de données int.
Débordement arithmétique.
Donc j'ai modifié le type en BIGint.
La question est donc celle-ci: Dois-je transformer tous mes index de la
sorte ? Pourquoi l'assistant ne l'a pas fait lui-même dès le départ ?
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
zoltix
On 9 jan, 21:16, "GOLD" wrote:
Bonsoir, Je dois faire migrer une grosse application de gestion. Après conversion de la base access vers sql server, j'ai retrouvé les index primaires déclarés selon le type de données INT La plupart du temps j'ai du activer l'identité (spécification du c ompteur). Le fonctionnement de l'application a fonctionné correctement sans trop de bug... Mais après un certain temps j'ai reçu des messages d'erreur de la par t du serveur en particulier lors d'instructions INSERT
(0 ligne(s) affectée(s))
Msg 8115, Niveau 16, État 1, Procédure sp_sql_copy_marché_for_clien t, Ligne 18
Une erreur de dépassement arithmétique s'est produite lors de la conv ersion de IDENTITY en type de données int.
Débordement arithmétique.
Donc j'ai modifié le type en BIGint.
La question est donc celle-ci: Dois-je transformer tous mes index de la sorte ? Pourquoi l'assistant ne l'a pas fait lui-même dès le départ ?
merci d'avnce Cordialement Jacques
Il y a un truc qui me semble bizarre. Donne un peu la taille en nombre rows de ta tables( il y'a plus de rows > 2.147.483.647)..... et la définition de la table avec trigger, index...... Peut être 'id' de ta dernière row atteint ce nombre (> 2.147.483.647).....Ne devrais tu pas réinitialiser ce champ (l'index)?, car pour une question de performance je préférerais rester sur int que bigint. Ceci dit il y a pas une grande différence de performance mais en taille c'est le double. A+
Pour info
DBCC CHECKIDENT('Customer', RESEED, 0)
SELECT @@IDENTITY This is everyone's favorite function, unchanged from earlier versions of SQL Server. It returns the last IDENTITY value produced on a connection, regardless of the table that produced the value, and regardless of the scope of the statement that produced the value.
SELECT IDENT_CURRENT('tablename') This new function returns the last IDENTITY value produced in a table, regardless of the connection that created the value, and regardless of the scope of the statement that produced the value.
SELECT SCOPE_IDENTITY() This new function returns the last IDENTITY value produced on a connection and by a statement in the same scope, regardless of the table that produced the value.
-- SET IDENTITY_INSERT to ON. SET IDENTITY_INSERT dbo.Tool ON GO
-- Try to insert an explicit ID value of 3. INSERT INTO dbo.Tool (ID, Name) VALUES (3, 'Garden shovel') GO
On 9 jan, 21:16, "GOLD" <jag...@free.fr> wrote:
Bonsoir,
Je dois faire migrer une grosse application de gestion.
Après conversion de la base access vers sql server, j'ai retrouvé les index
primaires déclarés selon le type de données INT
La plupart du temps j'ai du activer l'identité (spécification du c ompteur).
Le fonctionnement de l'application a fonctionné correctement sans trop de
bug...
Mais après un certain temps j'ai reçu des messages d'erreur de la par t du
serveur en particulier lors d'instructions INSERT
(0 ligne(s) affectée(s))
Msg 8115, Niveau 16, État 1, Procédure sp_sql_copy_marché_for_clien t, Ligne
18
Une erreur de dépassement arithmétique s'est produite lors de la conv ersion
de IDENTITY en type de données int.
Débordement arithmétique.
Donc j'ai modifié le type en BIGint.
La question est donc celle-ci: Dois-je transformer tous mes index de la
sorte ? Pourquoi l'assistant ne l'a pas fait lui-même dès le départ ?
merci d'avnce Cordialement Jacques
Il y a un truc qui me semble bizarre. Donne un peu la taille en
nombre rows de ta tables( il y'a plus de rows > 2.147.483.647)..... et
la définition de la table avec trigger, index......
Peut être 'id' de ta dernière row atteint ce nombre (>
2.147.483.647).....Ne devrais tu pas réinitialiser ce champ
(l'index)?, car pour une question de performance je préférerais
rester sur int que bigint. Ceci dit il y a pas une grande différence
de performance mais en taille c'est le double.
A+
Pour info
DBCC CHECKIDENT('Customer', RESEED, 0)
SELECT @@IDENTITY
This is everyone's favorite function, unchanged from earlier versions
of SQL Server. It returns the last IDENTITY value produced on a
connection, regardless of the table that produced the value, and
regardless of the scope of the statement that produced the value.
SELECT IDENT_CURRENT('tablename')
This new function returns the last IDENTITY value produced in a table,
regardless of the connection that created the value, and regardless of
the scope of the statement that produced the value.
SELECT SCOPE_IDENTITY()
This new function returns the last IDENTITY value produced on a
connection and by a statement in the same scope, regardless of the
table that produced the value.
-- SET IDENTITY_INSERT to ON.
SET IDENTITY_INSERT dbo.Tool ON
GO
-- Try to insert an explicit ID value of 3.
INSERT INTO dbo.Tool (ID, Name) VALUES (3, 'Garden shovel')
GO
Bonsoir, Je dois faire migrer une grosse application de gestion. Après conversion de la base access vers sql server, j'ai retrouvé les index primaires déclarés selon le type de données INT La plupart du temps j'ai du activer l'identité (spécification du c ompteur). Le fonctionnement de l'application a fonctionné correctement sans trop de bug... Mais après un certain temps j'ai reçu des messages d'erreur de la par t du serveur en particulier lors d'instructions INSERT
(0 ligne(s) affectée(s))
Msg 8115, Niveau 16, État 1, Procédure sp_sql_copy_marché_for_clien t, Ligne 18
Une erreur de dépassement arithmétique s'est produite lors de la conv ersion de IDENTITY en type de données int.
Débordement arithmétique.
Donc j'ai modifié le type en BIGint.
La question est donc celle-ci: Dois-je transformer tous mes index de la sorte ? Pourquoi l'assistant ne l'a pas fait lui-même dès le départ ?
merci d'avnce Cordialement Jacques
Il y a un truc qui me semble bizarre. Donne un peu la taille en nombre rows de ta tables( il y'a plus de rows > 2.147.483.647)..... et la définition de la table avec trigger, index...... Peut être 'id' de ta dernière row atteint ce nombre (> 2.147.483.647).....Ne devrais tu pas réinitialiser ce champ (l'index)?, car pour une question de performance je préférerais rester sur int que bigint. Ceci dit il y a pas une grande différence de performance mais en taille c'est le double. A+
Pour info
DBCC CHECKIDENT('Customer', RESEED, 0)
SELECT @@IDENTITY This is everyone's favorite function, unchanged from earlier versions of SQL Server. It returns the last IDENTITY value produced on a connection, regardless of the table that produced the value, and regardless of the scope of the statement that produced the value.
SELECT IDENT_CURRENT('tablename') This new function returns the last IDENTITY value produced in a table, regardless of the connection that created the value, and regardless of the scope of the statement that produced the value.
SELECT SCOPE_IDENTITY() This new function returns the last IDENTITY value produced on a connection and by a statement in the same scope, regardless of the table that produced the value.
-- SET IDENTITY_INSERT to ON. SET IDENTITY_INSERT dbo.Tool ON GO
-- Try to insert an explicit ID value of 3. INSERT INTO dbo.Tool (ID, Name) VALUES (3, 'Garden shovel') GO
