Monday or Tuesday we'll be releasing a product called Lh2TXT. It's

a utility to chrun out AREV/OI tables to ascii text files. It

does not use OI in any way. This is DIRECT access.

From there a user can import into Access, dbase, whatever to report

or process otherwise.

It supports batch processing, dictionary conversion, and more. And it's extremely fast (18,000 records of 350 bytes each in 30 seconds on a 233!, approx 7MB of output, 5MB of input). This is a 32-bit utility.

OR, If your really hardcore, and this is NOT a joke or vaporware, we are putting the finishing touches on our 32-bit DLL for use with

32-bit versions of Visual Basic. Now you too can write apps and utilities that will read those OI files directly!

Check it out at www.bizsoftcorp.com even though there's not much about it there. We are hard at work getting it out the door.

Did you ever stop to consider that to advertise a

product which fosters a migration path *away* from

RTI products in these forums is a little unethical?

Sure the knowledge is available readily, via

technical bulletins, and example programs on the www.

Sure there are other output paths, such as 123 or

dBase or ASCII exports.

Your product is probably elegant. But does it serve

to protect the AREV market which has obviously been

commercially beneficial to you? If not, why advertise

it here?

Steve Smith

http://www.ozemail.com.au/~stsm

I have to disagree. If users wanted to move away from OI they would use another package alltogether. The exporting that OI does is just that, it exports. This is only useful when you don't want real-time access to data, which I think is rare. By offering the DLL they are allowing users to develop in 32 bit front ends to OI since Revelation has abandoned 32 bit development. I wrote an automation server that lets me talk to OI via the Visual Basic part of my application (the app is a hybrid). I needed to use drag and drop and OI does not have it. I'm actually looking forward to this DLL as I'd like to write an ISAPI extension to start accessing rev data via Java.

I really don't think they are offering it as a migration path, just another enhancement we can use as we continue to use OpenInsight. If users want to migrate from OI they could just take the C/S Workspace and move the data out and get out alltogether. I think it may even have the opposite effect. If users have the option of continuing to use their linear hash tables with a 32 bit front end they are less likely to fully abandon OI. They can have full 32 bit software for their local applications and use the forthcomming JRev for their intra/internet apps.

Bryan

bfeddish@netreach.net

I think it is beneficial to have this product, because I believe that it is important to allow the LH format to reach a wider audience. I don't feel it is unethical to promote it on this forum. As a Revg/Arev developer of 15 years, I feel the greatest threat to the Arev/LH 'way of life' is isolation from the broader trends that are occurring in the database development world. I hope this product will stimulate others (and RevTech also) to consider the benefits of making LH a data management alternative that is accessible from a variety of languages.

I have been using a beta version of a 16 bit ODBC driver developed by 4C solutions. I have a decision to make very soon, either I purchase the driver i am using now, or find another solution.

So.. The question is, what does this solution offer that an Odbc driver doesn't?

My main requirements are Reporting (I am using Crystal presently) and Excel Spread sheet access.

Being tied to 16 bits is a hastle, but I have been promised a 32 bit driver this quarter.

Comments or suggestions would be appreciated.

April, do you have an email address for 4C Solutions?

Skip

I kinda look forward to the VB dll. I find some of the interface

development in OI painful. Is there any 3rd party books that are

worth buying for OI?

View this thread on the forum...