La largeur du champ numérique dans le fichier DBF est incohérente lorsqu'elle est créée avec oleDB (.NET)

Question

OleDB ajoute toujours un chiffre supplémentaire aux champs numériques DBF lorsque nous les créons. Une commande comme celle-ci: CREATE TABLE [file1.DBF] ([MY_FIELD] NUMERIC(1,0) NULL) créera un champ pouvant contenir 2 chiffres (ou un chiffre et un signe moins). Ce qui est drôle est que je peux demander une longueur de zéro comme ceci NUMERIC(0,0) et il va créer un champ avec une longueur de 1.

Je n'ai trouvé aucune documentation concernant ce comportement.

Est-il spécifique à l'utilisation de oleDB pour créer DBF ou la même chose peut arriver avec d'autres DB?

Le caractère supplémentaire ajouté par oleDB est-il uniquement utilisé pour gérer le signe moins?

Ce comportement est-il cohérent? Je veux dire, puis-je soustraire un à la largeur quand je crée la table?

Edit: Cette question a été à peu près répondu ici: http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/af245580-8897-4608-8fa0-f00286d37324?prof=required

Answer 1

Il pourrait être aussi simple que l'interprétation de base zéro par rapport à base d'un, mais vous pouvez trouver intéressant.

Answer 2

On dirait que DRapp pourrait être sur quelque chose.

CREATE TABLE [file1.DBF] ([MY_FIELD] NUMERIC(1,0) NULL) 

de FoxPro crée:

Structure for table: FILE1.DBF 
Number of data records: 0  
Date of last update: 08/24/10 
Code Page:    1252  
Field Field Name  Type    Width Dec Index Collate Nulls 
    1 MY_FIELD  Numeric     1       Yes 
** Total **         3 

SQL même par OleDb crée:

Structure for table: FILE1.DBF 
Number of data records: 0  
Date of last update: 08/24/10 
Code Page:    1252  
Field Field Name  Type    Width Dec Index Collate Nulls 
    1 MY_FIELD  Numeric     2       Yes 
** Total **         4 

Mais, CREATE TABLE [file1.DBF] ([MY_FIELD] NUMERIC(0,0) NULL) par OleDb crée:

Structure for table: FILE1.DBF 
Number of data records: 0  
Date of last update: 08/24/10 
Code Page:    1252  
Field Field Name  Type    Width Dec Index Collate Nulls 
    1 MY_FIELD  Numeric     1       Yes 
** Total **         3 

La même structure que celle de F oxPro. Pour une raison quelconque, cela indique qu'il existe une différence de comportement entre le moteur FoxPro et le pilote VFPOLEDB.

Answer 3

Il n'y a pas que le comptage basé sur zéro. Si vous exécutez la commande suivante via OLEDB:

ALTER TABLE MyTable ADD COLUMN n_value N(5, 4) 

Vous obtenez un champ avec une taille de 7, et non 6. En outre, N(6, 4) cède N(8, 4). Ce comportement est le même pour le pilote ODBC.

KB #150434 Cependant, même cet article ne décrit pas précisément le scénario ci-dessus avec 4 décimales. Mon test montre que l'équation de taille est (à partir du code C#):

if (places <= 1) 
{ 
    size -= 1; 
} 
else 
{ 
    size -= 2; 
} 

j'ai pu mettre à jour des centaines de différentes colonnes en utilisant une variété de longueurs de colonnes numériques, et tous mis à jour comme prévu.