OleDB CreateTable

Det er dBase III filer jeg arbejder med, hvis det gør en forskel.

Desuden kan jeg se i mine input filer, at ID feltet i disse er specificeret som Long Integer. Så måske spørgsmål 1 skal ændres til, hvordan man opnår at ID feltet er Long Integer.

OleDbConnection har en GetOleDbSchemaTable metode som kan bruges til at lede efter tabeller med.

Integer burde vaere rigtig.

Hmmmm, What to do?

ArcGis, Excel, samt Notepad inspektion fortæller mig, at ID feltet i dBase filen er en double.

Kan det have betydning at jeg forsøger at skrive 7-cifrede Integers, eksempelvis 1002897 (listes som 1002897.00000 i Notepad)

Kan man forsøge at lave kolonnen om til Long Integer?

int id;
double field1Val, field2Val, field3Val, field4Val;

..... Assign values to fields

command.CommandText = string.Format("INSERT INTO {0}(ID, Field1, Field2, Field3, Field4) VALUES({1}, {2}, {3}, {4}, {5})", fileName, id, field1Val, field2Val, field3Val, field4Val);

Jeg har prøvet at isolere logikken i følgende TestKlasse. Jeg ender stadig op med et ID felt af typen double og er løbet tør for idéer. Hvad kan man gøre?

class Program
{
  static void Main(string[] args)
  {
      const string tableName = "MiniTest";
      const string folder = @"C:\Output";
      string connectionString = string.Format(@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};Extended Properties=dBASE III;", folder);

      OleDbConnection con = new OleDbConnection(connectionString);

      try
      {
          con.Open();

          OleDbCommand create = con.CreateCommand();
          create.CommandText = "CREATE TABLE " + tableName + ".dbf (ID INTEGER, Field1 DOUBLE, Field2 DOUBLE, Field3 DOUBLE, Field4 DOUBLE);";
          create.ExecuteNonQuery();

          const int id = 1002897;
          const double field1Val = 12d;
          const double field2Val = 23d;
          const double field3Val = 34d;
          const double field4Val = 45d;

          OleDbCommand insertCmd = con.CreateCommand();
          insertCmd.CommandText = string.Format("INSERT INTO {0}(ID, Field1, Field2, Field3, Field4) VALUES({1}, {2}, {3}, {4}, {5})", tableName, id, field1Val, field2Val, field3Val, field4Val);

          insertCmd.ExecuteNonQuery();
      }
      finally
      {
          // Close connection.
          con.Close();
      }
  }
}

Nu har jeg lige checket min gamle DBF kode (C kode).

Og det giver måske lidt mening. Fordi - DBase III DBF har ikke integer data type overhovedet - den har kun DECIMAL og FLOAT.

Prøv og definer id til at være f.eks. DECIMAL(10,0) og se om ikke den så "ligner" en integer.

Ellers må du nok bare leve med det.

Hej Arne

Tak for hjælpen. Smid et svar, så er der point.

Jeg er nok nødt til at sluge double feltet indtil videre, for jeg kan ikke finde en vej uden om problemet.

Jeg arbejder med Esri Shapefiles, hvor dbf filer er en del af den overordnede filtype.

Gennem Esri ArcGIS kan man oprette DBF filer og der er det faktisk muligt at specificere både Integer og Long Integer datatypen.

Jeg har læst mig til, at Shapefiles skulle være baseret på dbf IV filer, men at det er bedst at benytte dbase III for backward compatibillity.

Så vidt jeg kan lure understøtter dBase IV heller ikke et Integer felt, så noget stemmer ikke helt overens.
http://www.clicketyclick.dk/databases/xbase/format/data_types.html

Jeg tror, at løsningen bliver at gemme en tom sketch version af dbf filen oprettet gennem ArcGIS og så kopiere filen inden skrivning. Har dog ikke tjekket om OLEDB vil være med på den fremgangsmåde.

Der er som sådan ikke noget problem i, at ID feltet er double, udover at fil størrelsen bliver større pga af de 5 overflødige ".00000" i hver række.

Du kunne ikke slippe af med decimalerne ved at bruge DECIMAL(10,0) ?

Og et svar.

Hej Arne

Det gjorde ikke umiddelbart nogen forskel med Decimal(10,0). Der er stadig kommaer i ID kolonnen. Men GetOleDbSchemaTable er en super funktion. Meget brugbar.

Desuden er jeg også lige løbet imod en mur, da jeg forsøgte at databinde til en dbf fil, så jeg er pænt træt af ESRI Shapefile formatet, der altså inkluderer .dbf.

Derfor har jeg lige konverteret alle mine eksterne input filer til ESRI's GeoDatabase format(.mdb) og det har gjort tingene meget nemmere.