• expression error ( in index key )

    From Scott Coffey@none@noemail.com.invalid to comp.lang.xharbour on Mon Feb 19 13:28:53 2024
    From Newsgroup: comp.lang.xharbour

    Hoping for a minor miracle here...

    I have a Clipper application running on a handheld device (Pocket PC).
    I'm using PocketDOS as the OS on the handheld device. I'm trying to
    port this application to a handheld running Windows CE 7.0. Although
    I had some issues installing PocketDOS on the Windows CE device (was
    unable to use the installer and had to install manually), I got it
    installed and am able to launch and run the Clipper application on
    this device.

    The application runs fine until I try to create an index, then the
    application fails when I try to use that index.

    Example:

    Program A uses the following statement:

    use c:\SCANFILE.DBF index C:\SCANFILE.NDX alias SCANFILE

    That works fine as long as I'm using the original index created on the
    old Pocket PC handheld. Then I have a program that does:

    if file( "SCANFILE.DBF" ) = .T.
    if file( "SCANFILE.NDX" ) = .T.
    erase ("SCANFILE.NDX")
    endif
    use SCANFILE.DBF
    index on ITEM to SCANFILE.NDX
    endif

    That runs OK, but the next time I try to run program A, it fails on
    the "use" statement with the error: "expression error ( in index key
    )"

    The database files and indexes were copied from the working device to
    the new device. As stated, accessing the database files via the index
    works OK initially, but when I try to recreate the index the program
    then fails as described. If I re-copy the files, the program works
    again until I try to recreate the index.

    Any ideas out there?
    --
    Scott at Scott dash(-) Coffey dot net
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Enrico Maria Giordano@e.m.giordano@emagsoftware.it to comp.lang.xharbour on Mon Feb 19 19:37:30 2024
    From Newsgroup: comp.lang.xharbour

    Are you using xHarbour or Clipper?
    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Scott Coffey@none@noemail.com.invalid to comp.lang.xharbour on Tue Feb 20 08:27:35 2024
    From Newsgroup: comp.lang.xharbour

    On Mon, 19 Feb 2024 19:37:30 +0100, Enrico Maria Giordano <e.m.giordano@emagsoftware.it> wrote:

    Are you using xHarbour or Clipper?

    Clipper S87.
    --
    Scott at Scott dash(-) Coffey dot net
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Enrico Maria Giordano@e.m.giordano@emagsoftware.it to comp.lang.xharbour on Tue Feb 20 15:03:14 2024
    From Newsgroup: comp.lang.xharbour



    Il 20/02/2024 14:27, Scott Coffey ha scritto:

    Are you using xHarbour or Clipper?

    Clipper S87.

    It seems that the new index is not identical to the old one. Check the
    index type (NDX/NTX/...) and the index key.
    --
    Enrico Maria Giordano

    http://www.emagsoftware.it
    http://www.emagsoftware.it/emgmusic
    http://www.emagsoftware.it/spectrum
    http://www.emagsoftware.it/tbosg

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Dlzc@turkeyheadedmutha@gmail.com to comp.lang.xharbour on Tue Feb 20 07:42:35 2024
    From Newsgroup: comp.lang.xharbour

    On Tuesday, February 20, 2024 at 8:03:17rC>AM UTC-6, Enrico Maria Giordano wrote:
    Il 20/02/2024 14:27, Scott Coffey ha scritto:

    Are you using xHarbour or Clipper?

    Clipper S87.
    It seems that the new index is not identical to the old one. Check the
    index type (NDX/NTX/...) and the index key.
    S'87 manual Appendix F says the they "key" is damaged. I wonder if the executing program and indexing program are using the same version of compiler and libraries?
    David A. Smith
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Scott Coffey@none@noemail.com.invalid to comp.lang.xharbour on Tue Feb 20 11:56:51 2024
    From Newsgroup: comp.lang.xharbour

    OK, after doing some additional research, it appears there's a problem
    with databases in general.

    I have an application that writes records to a database. The writes
    appear to be happening (I can open the database in Advantage Data
    Architect and the records are there), but I can't read those records
    in a subsequent program. The file being written to has no keys and no associated indexes. So I can write to the file but can't read those
    records from the file.

    I have the handheld application working on a development PC. I can
    take the file that was written on the handheld and copy it to the PC,
    and the PC program reads the records with no problem.

    The same handheld program that writes the records to the database
    first validates that the item number being written is valid, so it
    does a lookup via an index on another database. That function is
    working. So it can access a database via index to validate a number,
    but it can't read do straight reads from a database file.

    Here is my compile script:

    Clipper C:\Handheld\%1 -oc:\Handheld > errors.txt
    IF NOT ERRORLEVEL 1 BLINKER FI C:\Handheld\%1 @c:\CLIPS87\BCL.LNK < C:\Handheld\C.TXT
    IF NOT ERRORLEVEL 1 DEL C:\Handheld\%1.OBJ

    Here is my link script:

    BLINKER INCREMENTAL OFF
    BLINKER EXECUTABLE CLIPPER F45
    #
    BLINKER CACHE XMS 1024, 25%
    BLINKER CACHE EMS 1024, 25%
    BLINKER OVERLAY FIXED
    #
    BEGINAREA
    #
    #LIB \CLIPS87\EXTEND
    #LIB \CLIPS87\NANFOR
    #
    ENDAREA
    #
    FILE \CLIPS87\NDX
    @\BLINKER\CLP\LNK\CL87MID.LNK

    In summary, the application works on a handheld running Pocket PC OS.
    It also works on a development box (A Windows 7 box running in XP
    mode). But it's failing on a handheld running Windows CE 7.0. The
    only different variable here is the PocketDOS implementation on the
    Windows CE device. I've tried reaching out to PocketDOS, but their
    stance is that it's a "DOS problem" and they can't help.

    Do any of you oldsters out there know of any DOS tweaks that might
    help here? Here is my autoexec.bat and config.sys:

    autoexec.bat:

    cls

    rem -----
    rem The following line sets the DOS PATH
    rem -----
    PATH A:\DOS

    rem ----
    rem Display drive settings (for information only)
    rem Type: SETDRIVE /? for more information.
    rem Note: SETDRIVE must be run from AUTOEXEC.BAT to enable saved
    redirections
    rem ----
    SETDRIVE NOBANNER
    echo.

    C:
    main.exe (<--- this is the Clipper executable)

    *************************

    config.sys:

    rem ----
    rem Load File System Redirector
    rem ----
    DEVICEHIGH=\DOS\PKTDOSFS.SYS

    rem ----
    rem Load Expanded Memory (LIM EMS 3.2) Driver
    rem ----
    DEVICEHIGH=\DOS\EMSMEM.SYS

    *************************

    Any ideas/suggestions are appreciated.
    --
    Scott at Scott dash(-) Coffey dot net
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Dlzc@turkeyheadedmutha@gmail.com to comp.lang.xharbour on Wed Feb 21 06:33:07 2024
    From Newsgroup: comp.lang.xharbour

    On Tuesday, February 20, 2024 at 10:56:55rC>AM UTC-6, Scott Coffey wrote:
    OK, after doing some additional research, it appears there's a problem
    with databases in general.
    ...
    Do any of you oldsters out there know of any DOS tweaks that might
    help here? Here is my autoexec.bat and config.sys:

    autoexec.bat:

    cls

    rem -----
    rem The following line sets the DOS PATH
    rem -----
    PATH A:\DOS
    ... note the path.

    DEVICEHIGH=\DOS\PKTDOSFS.SYS
    So you are instructing the OS to look in A:\DOS\DOS\... for that particular program. Why don't you display line by line (as makes sense) any error messages that you might be ignoring from instructions to 'DOS'?
    DEVICEHIGH=\DOS\EMSMEM.SYS
    ... ditto
    Any ideas/suggestions are appreciated.
    Before first line of executing code, add a diagnostic. Run DIR and wait, or run ADIR() and analyze. See where the code is looking for database and index. Alternatively, issue a SET DEFAULT to the druive and directory you want it to look in. Do this same thing for the code that (re)creates the index, or incorporate in the one program. S'87 had some limited error trapping, could put the code there.
    David A. Smith
    --- Synchronet 3.21d-Linux NewsLink 1.2