Does anyone know if there are commercial products available that will allow us to access SQL tables data from Arev? Or SQL from Open Insight?

I have look on the forums here, and found a few things that might work, but all require quite a bit of "roll-your-own" work, even the ODBC driver (reserved words such as DESC etc etc).

We hope to that spending $ will shorten development time.

Reply here, or to rj_revtech AT yahoo DOT com

OpenInsight can access SQL tables directly and transfer into AREV files… this would seem the easiest way forward and is very straightforward.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Your best bet is to connect through openInsight ..

From their it really becomes very 'easy'. You may either 'roll your own' as you say using the xo connection object OR you can use datasets and use OIs window process to process a row at a time like normal oi data.

For one client, several years ago, i created a set of routines including and MFS which allowed READ, WRITE etc to work against the SqlServer tables.

Possibly if you give us an idea of where you are trying to get we can better define the mode of transportation

DSig

The dream is from within an AREV R/BASIC program to be able to treat an MS-SQL database as if it where Arev data. While I have specified MS-SQL we aren't even that particular, it's just the "other" database we have at the moment.

So that dream is Read, Write, Delete and Select rows from the SQL table from WITHIN Arev. The Arev commuter module to an Arev window could display SQL data in it for view and/or update.

Beyond that we don't have any specifics.

So OI isn't quite the ticket as it seems we would have to convert our EXTENSIVE set of Arev screens into OI GUI screens, upgrade all our data dictionaries to OI standards (and possibily force re-indexing on 10million row LH data tables due to our lack of data validation on these fields) etc etc. Or is this assumption about converting to OI incorrect? Can I use OI to do this, without converting the Arev apps to OI?

Why are you switching to a SQL back-end?

We aren't switching to a SQL backend. But we do have some important data from our web systems, that needs to get into our Arev system, that is in SQL.

For example, customers can change their self-assigned password that allows accesses to the web content. But our Customer Service staff, who use Arev screens, can't see that password, nor easily help the customer who messes up and foregets it, types it in all caps, etc.

So we'd like that Customer Service rep to see that password and be able to change it, from one of our Arev screens. These many Arev screens have ALL the customer information/business rules (orders, payments, return auth, refunds, inventory, credits, shipping address, etc etc etc).

So believe that it is much easier to get Arev to read/write the SQL data, than to switch all our screens to something that can read/write SQL data (but still can't read the Arev data).

=== At 06 JUN 2005 12:03PM support@sprezzatura.com wrote: ===

Well in theory the SQL Server Bond should still work if Rev will sell it to you :)

Failing that you could write a polling based exchange between AREV and OI. Shared data file, AREV writes a request, OI picks it up, grabs the SQL data and writes the info back to the shared file. Eminently achievable - similar to how we implemented our AREV based SMTP mailing software.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Something that is very SQLserver specific is to use DTS (data transformation Services )

SQLServer has GUI tools to define a set of steps which will copy data into or out of SQL server tables. It is possible to run these scripts from a command line. Thus, you on the SQL side you can define data-in and data-out dts scripts. From Arev you can use suspend exit DTSRUN "myscript" see DTSRUN Docusmentation" to talk to SQL via tab-delimited, csv or XML flat files.

For a generic approach, use OI as for the ODBC connector as recommended by Dsig and Sprezz. If you do not want to communicate via polling, try using XREV.DLL to kick off an Oengine, have the engine run your request, return control to Arev when done. Use Shared Rev tables to hold the query and the response.

Thanks to all!

This is bit to think about. Here's the summary of choices:

1. Use OI.

2. Use Sql DTS Service.

3. Use the olde Sql-Arev Bond.

Since we have more Arev talent than SQL (how many IT shops can say that today?) and that bond scares me, I think are best off using OI and creating a hybrid Arev-OI app.

Our Arev runs on Netware servers, fyi. So I can try and sell this to the boss, please let me know if I have gotten this straight:

1. We need a current copy of OI (our latest is 3.x) of several license counts. One per server side process, or one per server, or one per process per server? And Works for support for that.

2. OI works (pun ha ha) with the Netware NLM 5.5, so we are good.

3. We need the SQL ODBC driver from 'those other guys'.

4. We do not need the Web Deployment Pack or the Rev ODBC driver.

5. Do some testing in our environment to pick the best of

 a.  XREV.DLL "advanced" polling like b.

 b.  OI OpenEngine SQL-ODCB connection obtains data 

     when polled by Arev and returns that data.

 c.  MFS via Sigs suggestion.

1. - which ever goes fastest and is most scalable/reliable.

I have just now realized the ONLY tables that need to be shared in this farily simple hybrid app are the 'polling in/out' tables. Right?

If my assumption is true this avoids looking at and maybe then upgrading 6,607 symbolics to OI standards, because under the polling method, Arev would write the Arev data, and OI would write (via ODBC) the Sql data. The Arev-OI sharing is via the 'polling' tables.

Your assumptions seem initially correct.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Does the web data need to be in SQL? How about putting it native into ARev and using SWeb as the web interface?

Sprezz is too modest to mention it, but that doesn't prevent me for saying anything :)

The data is in Sql and the effort to re-code that system to Arev or OI (or anything else for that matter) would be a several man-year project so that just won't get done.

Wasn't here when the Sql decision got made.

View this thread on the forum...