fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC:

dbMigration with odbc // curiosity 20 Mar 2021 11:08 #17815

  • FFF's Avatar

  • FFF

  • Topic Author


  • Posts: 1110
  • Guys,
    for syncing dbf with Postgres tables i use dbMigration, a sub tool of Database.net.
    Usually that's all great, but now i found some peculiarity: it reads via odbc a series of dbfs as source - the tool lists all tables in the folder, some preselected for processing, as given by the commandline - but one table is missing. The table is physically there, is used by my apps, it even exists a copy in the folder, which IS shown.
    The odbc connection uses the MS VisualFoxpro driver. I even made another user conn, using another version of the driver on my machine - the result is exactly the same.

    In the developer's opinion, the odbc driver is at fault, but i can't imagine, what and why the problem exists at all.
    Anyone an idea?
    Regards
    Karl (X# 2.7; Xide 1.27; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity 20 Mar 2021 11:33 #17816

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2567
  • Hi Karl,
    if you build a small VO sample app using this ODBC driver (the StdMDI SQL Application should be enough): do you see your table?
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity 20 Mar 2021 15:18 #17817

  • FFF's Avatar

  • FFF

  • Topic Author


  • Posts: 1110
  • Hi Wolfgang,
    thx, didn't know, this sample exists ;)-
    built it, run, selected the datasource, "open a slq-table" - lists the dbfs in the folder, but not that dratted one.
    Opened explorer, made a copy of the file, and made a copy of the pre-version (which was corrupt) - the latter is shown, while the first is invisible like its parent.
    There's no problem at all opening it with the rdd/dbserver.
    Strange...
    Regards
    Karl (X# 2.7; Xide 1.27; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    Last edit: by FFF.

    dbMigration with odbc // curiosity 20 Mar 2021 15:37 #17818

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2567
  • Hi Karl,
    maybe this table has a field that is not valid for FoxPro?
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity 20 Mar 2021 15:49 #17819

  • FFF's Avatar

  • FFF

  • Topic Author


  • Posts: 1110
  • 8 fields, each "character", length 2, 4, 5 and 60...
    Regards
    Karl (X# 2.7; Xide 1.27; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity // solved? 30 Mar 2021 21:00 #17903

  • FFF's Avatar

  • FFF

  • Topic Author


  • Posts: 1110
  • Guys,
    to bring this to a conclusion: just tried and let cmVODBX make a "safe copy" of my problem dbf, what basically makes a new dbf using the struc and copy recordwise.
    And behold, this one gets listed by odbc.:P

    Ok, compared both of them with WinMerge and there's ONE difference, the first four hex values in the header are
    07 15 02 10 in the "problem" and
    03 15 03 1E in the working version

    Had had a look to file format definitions, where 0x03 means FoxBASE+/Dbase III plus, no memo (which is correct, this file has no memo field)
    but i find no info for 0x07 in the first byte

    As all my checks seem to work fine with the copy, i'm solved - but nevertheless, would like to understand what went wrong here.
    Regards
    Karl (X# 2.7; Xide 1.27; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    Last edit: by FFF.

    dbMigration with odbc // curiosity // solved? 31 Mar 2021 00:22 #17904

  • robert's Avatar

  • robert


  • Posts: 2118
  • Karl,
    First byte 0x07 is VO Ansi DBF. And first byte 0x87 is VO Ansi DBF with DBT.
    When you create a DBF with the DBFNTX driver in VO and when you have SetAnsi(TRUE) then you get this type of file.
    X# can read/write that.
    See github.com/X-Sharp/XSharpPublic/blob/mai...p.Rdd/Enums.prg#L105 for a list of types that X# knows about.
    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity // solved? 31 Mar 2021 22:12 #17909

  • FFF's Avatar

  • FFF

  • Topic Author


  • Posts: 1110
  • Robert,
    thx for this. All of my dbfs are CDX, all created with VO many moons ago. The ones with Memo are "0xF5", i.e. Foxpro2 (!)? The memo-less ones 0x03, i.e. "FoxBaseDBase3NoMemo".
    Slightly confusing, the whole thing, especially, why 0x07 isn't seen by odbc 3.00...
    Regards
    Karl (X# 2.7; Xide 1.27; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity // solved? 31 Mar 2021 22:17 #17910

  • robert's Avatar

  • robert


  • Posts: 2118
  • Karl,

    FFF wrote: Robert,
    Slightly confusing, the whole thing, especially, why 0x07 isn't seen by odbc 3.00...


    I do not think that the ODBC driver recognizes NTX files as well.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    dbMigration with odbc // curiosity 07 Apr 2021 00:16 #17965

  • mainhatten's Avatar

  • mainhatten


  • Posts: 167
  • FFF wrote: In the developer's opinion, the odbc driver is at fault, but i can't imagine, what and why the problem exists at all.
    Anyone an idea?

    As the original problem is already solved, let me add some vfp view:
    DO NOT USE VFP ODBC DRIVER IF YOU CAN CODE AROUND IT.
    The vfp ODBC driver has not been updated (IIRC from version 6) to keep in synch with newer features and additions.

    Code depending on it might work for long stretches, but then you need to access a table sporting one of the benefits added later, for instance BINARY index, and boom - you are out of luck and have to code around it, ask for other table or import format - things we dislike to do as it runs against DRY.

    OLE DB as access technology much safer, either in old COM/ActiveX surroundings as well as in ADO.Net - if the tool you use needs an ODBC driver (might be Linux based), use one from Advantage (from Advantage 10 or higher), it will work much further with newer vfp table features.

    If everything fails, fire up vfp as a COM object, access table in native vfp and pass the info back as stream, XML, JSON or create a file format to import in a cursor.

    Edit: see
    fox.wikis.com/wc.dll?Wiki~VFPODBCdriver
    for more details, like field types VarChar, AutoInc under "Can't" header...

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.
    • Page:
    • 1