IBMWorks database fails to open

[Barry Landy]

Using FAT32.IFS release 336 and opening the addressbook (aka phone) feature of IBMWorks the application opens with an apparently empty database.

It works fine in R290 and shows a populated database

the database is not damaged by the failure

[Barry Landy]

Attachment pim01.txt shows the attempt to open the database.

System R336 with trial version BL5 unzipped on top; running OS4 debug kernel and /monitor option for FAT32.IFS; T61 used as a serial port terminal to collect the trace

looking for \pim\now will show the various calls to FAT32.

[Barry Landy]

I think my comment above "no datasets are damaged" is wrong. There is a dataset in the pim\now database FPWPIM.INI which seems to vanish when trying to open the database in R336. It seems as though if the .ini file is missing it is recreated so it does not stop other versions opening the database (which is why I hadnt noticed before)

[Valery V. Sedletski]

Your log doesn't contain the moment of opening d:\d\pim\now\phone.dbf. I only see closing of that file in the beginning of the log. So please, take a full log. Start f32mon.exe before opening it. Or even, before starting IBM Works.

Also, you say that this .DBF file is not corrupted. But did you checked that additional files like database indexes are not corrupted too? Did you tried to recreate indexes? Also, I see opening the .INI file called D:\D\pim\now\FPWPIM.INI -- is it not corrupted too? I suspect that IBM Works may store some additional data about your .DBF file in such .INI's. So, these data may be lost, and so it closes the .DBF file.

I think my comment above "no datasets are damaged" is wrong. There is a dataset in the pim\now database FPWPIM.INI which seems to vanish when trying to open the database in R336. It seems as though if the .ini file is missing it is recreated so it does not stop other versions opening the database (which is why I hadnt noticed before)

Yes, that's what I said above: corrupting FPWPIM.INI may prevent your .DBF file to be opened.

PS: Please test ​ftp://osfree.org/upload/fat32/fat32-0.10-r337-os2.zip, I removed some unneeded debug messages. Also, there are some documentation updates.

[Barry Landy]

As I said above, the absence of the>INI file did not prevent the database being opened when using version R290 of FAT32.

Sorry about the log: it's the buffer size in putty; will try to increase.

[Valery V. Sedletski]

Could you try taking the logs when opening the .DBF file with both FAT32 versions, so I could compare them?

[Barry Landy]

OK. I increased the Putty buffer.

RUN 1: ECS22 with R290 running under OS2 kernel. G32MON started

database opened properly (I had to remove a lot of lines before and after the calls to PIM as the log was too big, but then I realised I could ZIP them)

Trace is in PIM02.zip

RUN 2: ECS22 with R337 running under OS4 debug kernel with /monitor and F32MON.

Database opens empty though I looked and the .INI file is still present

trace is in PIM03.zip

(if zips are inconvenient please say)

[Valery V. Sedletski]

It seems, I have a guess, why it's happening. Please try ​ftp://osfree.org/upload/fat32/fat32-0.10-r338-os2.zip, and see if your .DBF now opens ok.

[Barry Landy]

Great. That works. Unfortunately doesnt solve the ticket 67 problem....

[Valery V. Sedletski]

Good. This is I forgot to disable a flag in IFS, which means that locking file pieces is supported. I only implemented FS_FILEIO, but not FS_FILELOCKS, so it tried to call FS_FILELOCKS and failed. Now I returned it back.