expression error ( in index key )

[Scott Coffey]

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

[frank van nuffel]

Hi Scott,

1. if file( "SCANFILE.DBF" ) = .T.

why not use

if file( "C:\SCANFILE.DBF" ) // = .T. is not necessary

2 after that line, is SCANFILE.DBF still in use? Then first close it, only then erase SCANFILE.NDX

3 do you suppose correctly that the DBFNDX RDD doesn't work with production indices?
if DBFNDX does use production indices, then USE SCANFILE.DBF fails because there is no SCANFILE.NDX on disk (it got erased)

4 use SCANFILE.DBF

index on ITEM to SCANFILE.NDX

can be omitted when DBFNDX tries to open the production index, just write

use c:\SCANFILE.DBF

5 if DBFNDX doesn't work with production indices (i really don't know), then check whether there is a second SCANFILE.DBF somewhere trailing in your PATH; use SCANFILE.DBF uses the SCANFILE.DBF that it finds first

hth,

lohen

Op maandag 19 februari 2024 om 19:25:10 UTC+1 schreef Scott Coffey:

[Dlzc]

On Monday, February 19, 2024 at 12:25:10 PM UTC-6, Scott Coffey wrote:
> Hoping for a minor miracle here...

...
move this code first adding explicit references to the drive you say crashes.
> if file( "c:\SCANFILE.DBF" ) = .T.
> if file( "c:\SCANFILE.NDX" ) = .T.
> erase ("c:\SCANFILE.NDX")

> endif
> use SCANFILE.DBF
> index on ITEM to SCANFILE.NDX

... how do you know c:\ has been selected?

> endif
... then

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

> Any ideas out there?

Micro$haft never did like code writing to the root of the C-drive. Why do you? All that would need to happen is for the application to have selected the "working" or "program" directory for this to fail.

David A. Smith

[Scott Coffey]

Will certainly look at your suggestions.

Sorry to spam two different groups here... I'll be monitoring the
traffic in comp.lang.xharbour going forward.

Thanks

[Scott Coffey]

OK, belay that last message from me... I'll continue with this
thread...

Frank: I know the code is crappy, but I didn't write it, I'm only the
caretaker. :)

David: Thanks so much for your help... you've helped me many times in
the past.

I took your advice and created a folder in the root of C: on the
handheld to contain the application. The folder is called "HANDHELD".
I then added the following to the main calling program:

set default to C:\HANDHELD
set path to C:\HANDHELD

I then removed any specific references to C:\ in the program. For
example:

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

now reads:

use SCANFILE.DBF index SCANFILE.NDX alias SCANFILE

But, that didn't help with my problem.

The issue seems to be with writing to .DBF files.

In a part of the application, it writes records to a database file. I
wrote a few records and then exited the program. I then attempted to
open the file on the handheld device using Advantage Data Architect,
and it failed to open the file with an error message that said "The
table contains more or less records than specified in the table
header." (Using ADA to open other database files that I haven't tried
to write to works OK.) I then copied that file to my PC and it opened
with no error, but the file was empty. So, the problem lies with
writes to .DBF files somehow, or possibly with how DOS is handling the
file tables. (Reading from .DBF files isn't an issue... I have a
program that verifies item numbers by accessing a master file of items
in a .DBF file and that works just fine.)

To eliminate a problem with writes in general, I wrote a program that
wrote directly to a text file. Here is the code:

set default to C:\HANDHELD
set path to C:\HANDHELD
cTEXT = memoread( "SCOTT.TXT" )
cNEWTEXT = stuff( cTEXT, 1, 4, "CHANGE" )
memowrit( "SCOTT2.TXT", cNEWTEXT )

I was able to open 'scott2.txt' just fine on the handheld and it
contained the data I was expecting. So, there doesn't seem to be a
problem with writes in general, but only with writes to .DBF files.

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

I'm not sure what I can add/change here to affect writing to .DBF
files. Keep in mind that the applicatin has worked on two different
generations of handheld devices, as well as on my test box. Since the
only different variable here is (in theory) the version of PocketDOS
I'm using on the Windows CE device, it would seem that the problem is
there, rather than with the code or compiler. But I can't think of
any DOS configuration change that might help here. Here are my
autoexec.bat and config.sys files:

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:
cd handheld
main.exe

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

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


Sorry for the wall of text... just trying to provide all relevant
info.

Thanks

[frank van nuffel]

Hi Scott, so, your device (or combination of device and filesystem/os) isn't forcing read-only mode?

Do you boot your device with PocketOS? Or does it run under a VM?

F

Ps: accessing clc from Google, last hours before read-only Google usenet policy kicks in!

Op woensdag 21 februari 2024 om 19:00:29 UTC+1 schreef Scott Coffey:

> Scott at Scott dash(-) Coffey dot net

I'll resume at your address when required

[frank van nuffel]

Pocket OS _is_ a VM?

Does Pocket OS support FAT32? Does Windows CE have known issues with FAT32? Better not use a NTFS volume, even if Pocket OS supports it!

Do you combine the latest .libs for Clipper '87?

Does mounting to another drive letter than C:\ changes anything

>SETDRIVE NOBANNER

To me, there's the culprit - perhaps some incompatibility between SHARE (or Network Drive configuration at the Host OS, Windows CE) and Pocket OS

Just some ideas

Frank

[frank van nuffel]

Can copying your files from the source to the destination be done from within Pocket OS? Iow, does Pocket OS recognize external volumes (even NTFS volumes), then try installing everything into your Pocket OS volume by hauling over from your source volume, not via the Host OS?

Mind, i'm unfamiliar with Pocket OS, but it's worth trying

Frank