Discussion :

[Delphi-ne]

J'interviens sur une application qui doit migrer d'ACCESS vers SQL Serveur.
J'ai construit mes tables avec des Identity qui sont donc des BigInt et j'ai typé les champs qui devront établir les relations en BigInt.
Jusque là tout va bien

Par contre au nvieau d'ACCESS certains champs comportaient des valeurs négatives. Ces valeurs ont été transposées tel quel vers SQL Serveur

Lorsque je fait un Select via ADO je ne reçois que la valeur absolue. Le signe - des valeurs négatives a disparu.
J'ai essayé de récupérer mes valeurs avec FieldByName(*xxx').asinteger; FieldByName(*xxx').asstring; FieldByName(*xxx').value. Je ne retrouve jamais le signe -
L'anomalie disparaît sir je remplace le type BigiNT par Int.

Existe-t-il une solution plus propre ?

Merci d'avance

[ShaiLeTroll]

Tu prévois vraiment de dépasser 4 milliards d'enregistrement ?
2 milliards en négatif et 2 milliards en positif ?
Dans ACCESS tes valeurs sont signées sont compatible avec le INTEGER du SQL SERVER (si c'est le même que celui de Sybase)

Un bitInt ne semble pas utile pour tes Identity !
un Simple INTEGER me semble suffisant, il gère correctement le signe !
Par contre, si tu le déclare en IDENTITY, Sybase lui autorisait que l'on fournisse une valeur à un champ AutoINC, est-ce que SQL SERVER le supporte ?
D'ailleurs est-ce que le IDENTITY ne limite pas le INTEGER a des valeurs strictement positive ?

Si BitInt dans la DB alors le TField DOIT être un TLargeintField et utiliser via AsLargeInteger
Je ne connais pas SQL Server mais vérifie la classe du TField, est-ce détecté en TAutoIncField, ce dernier est limité à 2 milliards (aussi bien négatif que positif)
Et gérer un BitInt via un TAutoIncField ou TIntegerField c'est mort, il ne doit pas voir le bit de poids fort qui indique le signe (quoi que dans ce cas, tu n'aurais pas des valeurs absolues mais des valeurs farfelues)
Ou pire, il détecte un TUnsignedAutoIncField !

En DBX, Sybase Anywhere 10, la PK AutoInc était détecté comme un simple TIntegerField et non comme un TAutoIncField ce qui était assez pénible si l'on utilisait Insert\Post et ApplyUpdates

[Delphi-ne]

Merci

En ce qui concerne le choix BigInt je n'ai pas trop le choix. SQL Serveur impose ce type pour les Identity.
Il y a (hélas) des valeurs négatives dans les liens avec les Identity de certaines tables. Cela va m'interdire l'appliquer les contraintes de relation mais j'hérite de cette application et je n'ai pas le délai pour la réécrire.

J'ai trouvé hier soir la solution.
Il s'agit d'un bug dans ADODB identifié par Embarcadero.
La sotution est la suivante :

Code :

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

1
2
3
4
5
6
7
    ftLargeInt: With Decimal(Data) Do Begin
// 05.SEP.2002   Fixes a bug of the
      If sign>0 Then                            // 05.SEP.2002   inherited method
        LargeInt(Buffer^):=-1*Lo64              // 05.SEP.2002   which reads negative
      Else                                        // 05.SEP.2002   values as positive.
        LargeInt(Buffer^):=Lo64;
      End; //ftLargeInt

Je dois tester ce matin mais des premiers essais cela semble corriger.

[ShaiLeTroll]

Tu n'avais pas précisé que tu utilisais une version de Delphi vieille de 10 ans !
Ce n'est pas le seul bug ADO connu !

SQL Server qui oblige du BigInt !
C'est contraire à ce qu'indique la documentation du
IDENTITY et du CREATE TABLE

Indique que la nouvelle colonne est une colonne d'identité. Lorsqu'une ligne est ajoutée à la table, le moteur de base de données affecte une valeur incrémentée unique à la colonne. Les colonnes d'identité sont normalement utilisées avec les contraintes PRIMARY KEY comme identificateur de ligne unique pour la table. La propriété IDENTITY peut être affectée aux colonnes tinyint, smallint, int, bigint, decimal(p,0) ou numeric(p,0). Une seule colonne d'identité peut être créée par table. Il n'est pas possible d'utiliser des valeurs par défaut liées et des contraintes DEFAULT avec une colonne d'identité. Vous devez spécifier à la fois la valeur initiale et l'incrément ou aucune de ces valeurs. Si vous n'en spécifiez aucune, la valeur par défaut est (1,1).

A mon avis, c'est l'outil que tu utilises pour créer les tables qui te fait cela !
En faisant tes propres script SQL, tu auras plus de liberté !

[e-ric]

Salut

L'idée d'utiliser un BigInt ne me choque pas, par contre l'emploi, d'une clé négative m'interpelle, est-ce que ces clés ont un sens particulier dans ton application Access ?

Perso, quand j'utilise des clés négatives, elle ont un sens particulier du type "enregistrements système" que l'utilisateur ne peut pas modifier à sa guise. Si ce n'est pas le cas, peux-tu remplacer ces clés par de nouvelles (positives) ?

Mais attention aux règles d'intégrité.

@+

[Delphi-ne]

Je sais
L'idée de valeurs négatives dans des clés va impliquer l'absence de règles d'intégrité sur ces liens.
La seule solution serait de repenser et de réécrire cette applciation mais les budgets ne le permettent pas et mon rôle se limite à un transfert de ACCESS vers SQL Serveur.

Pour l'instant la modification sur l'unité ADODB semble avoir corrigé le souci.

J'attends la fin des tests pour mettre en résolu