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

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:
> 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

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

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 at Scott dash(-) Coffey dot net

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
--
Scott at Scott dash(-) Coffey dot net

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

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

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

On Wed, 21 Feb 2024 11:15:24 -0800 (PST), frank van nuffel
<fannuffel@gmail.com> wrote:

>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

Thanks for the reply Frank.

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

The device boots from Windows CE 7.0. I use a DOS emulator
(PocketDOS) to run my Clipper application.

The client is currently using an Intermec handheld device that runs
Pocket PC ver 3.0 OS. My goal is to port the Clipper application
(scanning/data entry) to a newer (newish) handheld running Windows CE
7.0. The application that is currently running on the Intermec device
also runs under the same PocketDOS emulator, although an older version
that is designed to run under Pocket PC OS.

PocketDOS allows mapping drives to folders on the handheld. On the
Windows CE handheld device there is the root (\) where Windows/Program
Files, etc. live. Then there is a folder called "Application" where
developer apps live. The device can be "reset", which takes
everything except the "Application" folder back to a factory state.
IOW, if you have something you want to survive after a reset, it
should live in the "Application" folder. So I have the C: drive
mapped to the "Application" folder. The A: drive is mapped to a
virtual boot disk. I have the Clipper app running from a folder
called "Houser" (client's name) inside the "Application" folder. So
from a DOS perspective, the true root of the device (where Windows
lives) is hidden. It only knows about things in the "Application"
folder, because that's where C: is mapped.

> 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!

Since the application runs under the DOS emulator, it doesn't know
about NTFS. It thinks it's running under DOS, so FAT32 is the file
system.

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

To the best of my knowledge. Keep in mind that the application has
run flawlessly for years under two generations of handheld devices
(Intermec and Janus). I haven't changed anything in my development
environment.

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

Possibly. I will probably try that next. Just caught Covid (again)
so not really in the mood to play with it ATM.

> 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

Not 100% sure I follow you.

The method of moving files from my dev box to the handheld is via
Microsoft's Active Sync/Windows Mobile Device Center. I develop the
handheld applications on a Windows 7 box running in XP mode (where
there is still DOS support) and then copy the .exe and database files
via XP --> Windows 7 --> Windows 10 --> Windows Mobile Device Center.
Connection from handheld is USB.

PocketDOS *does* support network drives, so I may try mapping that,
leaving the application files on my dev box to see if that changes
anything. It's not a long-term solution, but it may provide some
insight.

I'll try installing on a different drive than C: when I get a chance,
although I'm not too hopeful it will help. I was really hoping that
following David's advice to move the application off the root of C:
would buy me something, but no joy.

If I can't make any additional progress, I may suggest to the client
that we try a handheld running Windows Embedded rather than Windows
CE. I've already tried an Android based device, but the DOS emulation
available for Android leave a lot to be desired.

Thanks,
--
Scott at Scott dash(-) Coffey dot net