vDos Page Fault when starting application

[mrbigbear]

Hi Jos,

when we try to start our application the program quits with a message box coming from vDos (vDos - Exception / Page Fault: directory or table entry not set).

In that case we would test the current vDos Version (2019.05.01) with our application. Currently we running this software under the lastest available vDosPlus version without any pain!

Only the Network performance is poor and we have from time to time troubles with the Btrieve access.

I think the shit will happen when the program will open the first Btrieve file after start. Our Btrieve is for DOS (Btrieve/N Record Manager Version 5.10a).

Such Ideas???

Thanks & best regards,

Robert

[Jos]

You had the Page Fault exception with an earlier vDos version?

Btrieve 5.10a is known to be rock solid, so there should be no troubles accessing files. Maintaining a shared database is of course a real burden to the client based Btrieve. A single record update - changing one or more key values - will result in many read, lock and write operations.
If some databases are frequently updated/modified, you should periodically re-index, so the indexes are again balanced w/o logical index pages running over.
The only other option that comes to mind is the /F parameter. If missing from your Btrieve startup, it will only use the default 20 file handles. Causing Btrieve to frequently close and reopen files when those 20 file handles get exhausted.

The real solution is to switch to a server based database manager. But w/o DDF files that will be a lot of work.

Jos

[mrbigbear]

Hi Jos,

thanks for your quick response!

As suggested i made a test with vDos Version 2015.04.10, with this release it works!

Yes you are right, a change of the database maybe the best solution, but we have no possibilities to switch away from Btrieve or any other change on the DB layer.

Thx,

Robert

[Jos]

Don’t quite get the “As suggested…”.

The upcoming 2020.03.01 version would allow you to switch to for instance server based Pervasive. No changes needed to the program, it knows no better than still communicating with Btrieve 5.10a. Instead the Pervasive DLL will be used with translation of the two interfaces in between. The main challenge is however to convert the Btrieve database files to Pervasive data tables…

Jos

[mrbigbear]

Thx for your response and the information, are there any plans about the release date or any possibilities to get some prelease for evaluating?

Robert

PS: Yes you are right, the challenge is the data transformation, especially in our case there are some real strange data types.....

[Jos]

Version 2020.03.01 will be released March 1st .
Evaluating the Btrieve-Pervasive glue requires of course an operational Pervasive database. Though for testing purposes a client based Pervasive DLL would also do, but requires DDF files.

Besides indexed fields, Btrieve itself has no knowledge of what data types your program assigns to the remainder of the Btrieve data buffer. It’s just a block of binary (undefined) data to Btrieve. It’s your program that interpreters chunks of that remainder to sensible data. Only condition for transferring the data could be (I don’t know) that the indexed fields come first, continuously, then the remainder.

Jos

[mrbigbear]

Hello Jos,

thanks for your proposal about the release date.

I can hardly wait for and i would be very proud to see the btrieve glue working....

Currently i setup a system for testing....  The parts are a Windows Server 2016 with PSQL v10SP3 and one Windows 7 (32-Bit) box with installed PSQL 32-Bit Client.

The setup of the database was much more easier as i thought (Export and reload the data files with btutil). After this procedure the access from the app to the db works like a charm!

Best regards,

Robert

[Jos]

I assumed those illusive DDF files would always be needed for a transition to server based Btrieve. But I did my initial testing with client side Pervasive, and that actually needs those DDF’s.
Later testing was solely with MS SQL server (BTR2SQL replacing PSQL). Data tables in a non-PSQL database are inherently more complicated to replicate some Btrieve functionality.
But I also did the migration to MS SQL w/o the roundabout of creating DDF’s.
Since Btrieve files lack full record descriptions, I do assume your PSQL data tables only define the index fields, while all the rest goes into a binary container(s).

Jos

[fnavarro]

Jos,
I would like to know a little more about the mentioned functionalities. At first, personally it is more a theoretical issue, out of curiosity, although I understand there may still be some applicable niche.

Mainly about the direct connector to the Btrieve interface for Windows, about the interface to BTR2SQL, about BTR2SQL itself. It would be interesting to know the architecture of components in both cases and about licenses and costs in general. For example, the mertech site does not mention values ​​apparently. It is not entirely clear if in the case of BTR2SQL components (.sys or .dll) of PSQL would be used.

Another very specific curiosity, in the cases of programmers who can modify the source code of programs that use Btrieve, knowing that they would use the BTR2SQL interface, if one could pass SQL queries to the engine through the interface. I am thinking of a trick with some complexity, but what I imagine achievable, for example with the function "Get First" if it is sent with a special file name, which had to have n string-columns, replace it with a sql query. docs.actian.com/psql/psqlv11/wwhelp/wwhimpl/js/html/wwhelp.htm#href=btrieveapi/btrapi.2.01.html
The programmer would put the query in the key field (it should have enough characters) and each "Get Next" would fill the fields of that special table with the response fields. I.e. instead of get the first "SMITH" on "Customers", replacing "Customers" with "TSQL" for example and "SMITH" with "SELECT custName,SUM(total) FROM customers INNER JOIN ..."
It would involve changing the function mapping of the basic Btrieve Api in cases where the file name is that of the special table with B_SQL_* functions (such as B_SQL_OPEN_CURSOR, B_SQL_PREPARE, B_SQL_EXECUTE, and B_SQL_FETCH) info.mertech.com/hubfs/Mertech-Drivers/BTR2SQL/Mertech-BTR2SQL-Technical-FAQ-MySQL.pdf
It could be defined that it would close when all the results are consumed. I still understand that this is so specific and with some unforeseeable issues that it could be an effort with doubtful return, I just wanted to share the concern just in case.

Regards,
Federico

[Jos]

To migrate the Btrieve data files to MS SQL, I exported the data file description (by BLDBTB) to datafile.btb, and the data (by BUTIL) to datafile.txt while the DOS Btrieve 5.a TSR was loaded. Then I switched to using SQL_BTR.DLL (of BTR2SQL). Created the corresponding MS SQL table by BTFILER - Create file from BTB file - datafile.btb, and imported datafile.txt by BUTIL. Besides the index fields and binary remainder, the MS SQL table also has some calculated/virtual fields. One of these will for instance be to mimic the Get Position (22) and Get Direct (23) functions of Btrieve. Besides these additional fields, BTR2SQL also needs a .INT file for every former Btrieve data file to know its structure, and how to translate the file name (and path) to the MS SQL table name.

The SQL_BTR.DLL replaces the Pervasive DLL and has the same functionality (though towards a non-PSQL database). Like the DOS program has no clue it’s communicating with the vDos Btrieve glue instead of the Btrieve TSR, vDos doesn't care whose DLL it is connecting to, as long that DLL exports the correct entry point. I have no idea what the costs of BTR2SQL are, would expect them to be at least competitive to Pervasive.

From a (DOS) programmers point of view, it doesn’t matter whether Pervasive or BTR2SQL is used. The vDos Btrieve glue translates only the defined Btrieve API calls to those expected by the Pervasive/BTR2SQL interface. And on return of course back to what the Btrieve API should return. I have no intention to extend the DOS Btrieve API. Programs(mers) did without for more then thirty years, and I already have my doubts if the actual use of Pervasive/BTR2SQL in vDos will justify the work involved.

Jos

[fnavarro]

Thanks Jos,
That migration process seems very straight-forward.
Nice to see how those components plug together transparently.
I share you feelings about extending the API, it was more kind of thinking loud.

[fnavarro]

On second thoughts, perhaps the idea might be of interest to Mertech..

For those using the BTR2SQL bridge, would benefit using vDos even on 32bit Windows, right?

[Jos]

My first contact with Mertech started with: “This won’t be your daily inquiry or BTR2SQL usage, perhaps even a OMG:”.

I don’t think there will be many Btrieve users around for which the migration to a server based solution would be of real interest. Or (still) use a Pervasive server and DOS/NTVDM. If you had Btrieve or Pervasive/DOS and many users, you probably by now switched to a Windows alternative (program).
The BTR2SQL solution goes a step further, replacing the Pervasive by a common SQL server. Though a pity Mertech dropped the support for MySQL. Mertech’s audience will be the somewhat larger companies, running Windows software and wishing to move away from Pervasive. Mertech knows of the vDos Btrieve glue, got an one page instruction set of how to migrate Btrieve to BTR2SQL. But I doubt they will advertise BTR2SQL is also a alternertive for Btrieve DOS.

Jos

[fnavarro]

They have one blog page for Btrieve DOS from 2011 www.mertech.com/blog/how-to-run-a-dos-btrieve-application-with-a-sql-server

[Jos]

Didn't know of that document, while my contact was Thomas Oatman.
Could be Mertech lost interest, for instance the mentioned ReadDOS.txt isn't anymore.

I also don't know how usefull the article and referred white paper are. Pervasive components are needed (for the DDF files), I did it w/o those.
I had planned to add further field specs/descriptions to the migration process, and reserved two weeks to 'play' with the BTR2SQL trial. But simply ran short.
Didn't want to go into the trouble to ask for an extension, and decided it had to do. First await if there's any interest at all for this Btrieve glue, it already costed me far more than those two BTR2SQL trial weeks.

Jos