Here,s My story.

I started out in Rev G about twenty years ago. Don't remember too much about it these days. Later on we went to Arev & R-basic with bigger better screens and faster fancier codeing. The multivalued field stuff was really great too. It made me and my Arev buddies look like Bible heroes. Well they've all passed on now and I'm the only one left to carry on.

I remember when OI came out, things seemed to get just a wee bit more confusing. Some where along the way somebody suggested VB 4 or 5;

not too sure which one it was. Now that was along about the time a couple of Chinese programmers joined the team. Well VB 4 or 5, which- ever, came and left along whith the Chinese programmers. Of course not for the same reasons.

Well a few seasons came and left. The summers were hot and the winters were cold. Then all of a sudden we all got a new leader of the whole State of confussion. Things really started to change for everyone. All of a sudden we were all packing up our things for a little move down the street a bit - about two blocks or so. Anyway things just haven't been the same. 

Now we're back with another agency where we came from to start with years ago. And on top of that we're all to be put under another agency in the near future. No one seems to know what's going on or what's going to happen. 

Anyway, every body in this new place keeps talking  VB Studio.Net.

I'm stuck in the middle with no fiddle. And that's the name of that tune.

Guy's, please send me all the Info you can about .Net or .Not. I need to know what to do. I feel out numbered here. Every thing I have is in Rev format. It all seems so uncompatable with what everyone else here is doing. I need all of you fellow Arevers to join up with me in this fight to convince someone here that Arev can be helpful to keep. Any input to help explain the Good, the Bad, and the Ugly between Arev, OI, and Visual Basic .Net and MicroSoft would be helpful.

Thanks,

OLD S Bell

Sounds like you're fighting a losing battle.

Where did the idea of a Java virtual machine come from? REVG/AREV.

What do the AREV opcodes in object and the Java bytecodes have in common? Lots - that's where the idea came from.

Microsoft took AREV and tried to implement it in Windows. The answer was called Access - you may have heard of it.

Microsoft used to use HR-1=an AREV application=as their HR system. Probably still do. Dell tried to go to SAP, but went back to AREV.

.NET is basically to do with web connectivity. AREV and OI already do that. With less lines of code and better application manageability.

You want something that isn't influenced by Microsoft's OS patches. .NET is imperfect technology that falls over because of a lack of underlying development philosophy, and the fact that the OS entanglement is basically a difficulty they can't overcome. And it requires scads of hardware.

I'd turn around and suggest that the company leverage their existing code by adding a web interface, rather than re-inventing the wheel on the next short-lived Microsoft fad.

You can talk to AREV and OI via the web. You can talk to AREV and OI via Visual Basic. There are fewer lines of code in every AREV and OI application than in all Microsoft platforms. That's what you have to sell to your company. And the fact that AREV applications have a half life greater than that of Plutonium.

Talk to Sprezzatura about web enabling your applications. Talk to Revelation themeslves about converting the existing apps to OI or to AREV32 for a couple of thousand. Your company will spend less. And the dollars are compelling as an argument. That's the only unfair advantage you have.

Revelation has the perfect language. Better than .NET. Better than Cache (MUMPS) or Ruby or Python or PHP or VB or Access or Sybase or MSSQL or Java or anything. You can link OI to anything. It is brilliant as a procedural language.

Thanks Steve,

Your responce is a great start. Your draw was lighting fast,

Your aim was dead on, and when the smoke clears from it all,

I believe we'll have their attention.

Thanks agin. And to the rest of you Arevers, DRAW & FIRE AT WILL.

"Dell tried to go to SAP, but went back to AREV."

Since I was the Arev programmer during that time, I think I can chime in here. Yes, they tried to go to SAP. They actually went live with it for a full week, running parallel with HR-1. SAP was determined not to meet the requirements of Dell. Did they go back to Arev? I suppose so. But only until the replacement, HR Direct, was written in Seeker. They haven't been using Arev for years now. I've lost track of when the switchover took place, but it was in the late 90's I think.

Victor

Steve Smith -

Thanks you for your passionate response.

I

Steve Bell -

Some of my stock answers:

1. Consider Revelation to be a pre or proto-XML database.

We use single character delimiters where XML uses multi character delimiters, so XML can encode richer data structures.

We and XML use a meta table to decribe the data. XML calls the table a schema, we it a dictionary.

The xml schema has one rule type: "look here, you will find this type of data". We have that rule, we call it an F-type field. Unlike XML, Our schema supports other rules, called calculated fields. I predict that XML schemas will some day include the equivalent of calculated fields.

The core idea in the two technologies is the same: transacting smart text via simple protocols produces loosely coupled systems which survive change.

2. Consider Revelation to be a database which implements a relational view of an object oriented data store.

Start with the fact that Revelation stores data as a delimited string. Add the fact that we let you store multivalued lists or vectors inside of a column. Add the fact that we support calculated columns which can can return a scalar or vector list, which might be derived from several other tables or even other calculated fields. Add the fact that our MFS technology lets you trap every event which can occur on a table.

Now add buzzword compliance:

The fixed fields are "properties".

The calculated field are "methods".

The multivalued lists are "collections"

The MFS events are events.

A Revelation table is a "class", that string of data we call a record is a "serialized instance"

Note - our names and syntax are not consistent with Object Oriented conventions. But we get most of the benefits of Object orientation without needing to build a huge sotrware layer outside of the datbase.

3. Object-Oriented, part II.

Our calculated columns can derive data from other calculated columns. Calculated columns can derive data from other tables, or even other sources. For instance, I have created calcuated columns which do a google translation, or which call ADO lookups to SQL data. The point is that you can use a Revelation table to present a logical view of the data that is different from the physical implementation. You can change the underlying physical implementation and none of the tools consuming the logical view will know the difference. This encapsulation or inofrmation hiding is a key OO concept and a big reason we all like Revelation.

4. Transaction Oriented versus Set Oriented

Revelation is record oriented. That is, it is optimised to support reading and writing all data relevant to a single transaction as a single operation. When you construct a Revelation database, you lay it out to solve the problem at hand. SQL is set oriented. That is, it is optimised to support finding any subset of all of the data in the problem space. As Mike Ruane put it, "If you want soup, Revelation will hand you a can of soup, SQL will hand you the ingredients for soup". When you optimize for one thing you compromise on another. Revelation is optimised for transactions at the expense of set oriented reporting. Conversely, Sql is optimised for set-oriented reporting at the expense of transactions. Those expensive transaction managers that surround SQL databases are workarounds for this intentional weakness. In practice, one often cannot use the same SQL database for transactions and for reporting, becuase a badly written query brings the transaction system to its knees. The workaround for is to create a second database optimised for reporting. The name for that workaround database is "data warehouse". Now, if the SQL dba gets to build two databases, one for transactions and one for reporting, I should get to the same opportunity. Heck, use the same reporting tables that they do. The final application will have faster, simpler, cheaper transaction features and the same reporting prowess.

Hope this helps.

Bob

…Treadmill, the mighty lager…

[size=-3]

(looks up, notices empty room, quietly shuts door and turns out light as he exits)

By the way, I find similarities in the current predicament with the state of Texas and the situation Dell was in when they were getting rid of HR-1.

In the case of the state of Texas, the legacy system has an Arev front end, supported by one programmer (me), and a mainframe back end, supported by a handful of COBOL programmers. Screens, edits, business rules, etc. are implemented in Arev code. When a case is worked to completion, the case, with all its cleared screens is sent up to the mainframe, where a corresponding set of edits is performed. The mainframe additionally takes care of interfaces and some other things.

The system handles all foodstamp, TANF, and Medicaid applications for the state of Texas, totaling about 35,000 cases daily on a network of several hundred LANs.

A few years ago, a decision was made to replace this obsolete system with a state-of-the-art system using modern technologies. Thus began TIERS (Texas Integrated Eligibility Redesign System). A couple years later, in 2003, a pilot was started, where benefits are processed for a couple counties in the new application. The rest of the state still uses the legacy application. The idea is that as problems are identified at the pilot stage, they will be corrected and/or streamlined until more counties can be added.

The new system has dozens of developers (I don't know an exact number), and the project itself is now managed by Accenture, having replaced Deloitte, who ran the project initially. Now much politicking and cost overruns have people yelling to throw out Accenture.

Meanwhile, in order for inquiry on Tiers to be complete, cases in the legacy system are converted into HTML documents (by Arev), for read-only access by the new system. New cases are converted to HTML on a weekly basis. I also support this process, with one other person doing most of the work loading the HTML documents to a unix box and an Oracle database.

Meanwhile, the state and federal governments continue to impose changes on the system. Invariably, TIERS takes longer to modify to keep up with the changes than the legacy system does.

All in all, the legacy system is holding up very well. And from my perspective, the only thing really keeping it from lasting is the notion that it's a fait accompli that the legacy system is going away.

The latest progress on the new system is that another county is to go online either in November or January (3rd county out of 254?). Of course, the results of the upcoming election could change all that, too.

Victor

I worked on an AREV system that managed nuclear waste tracking and compliance reporting for a company. It was replaced by a system in Oracle, which took well over 1/2 dozen years to develop. The last few years, I was the only programmer (and scaled down from full time to contract called as needed) and there were 10 ORACLE employees on site (at more than full time), costs to finish were well into the millions (and had to be done as they had foolishly written their intention to use Oracle into an NRC compliance document). Amongst other improvements, they had a table to convert units (weights mostly) which didn't work correctly even years into the project (and the funniest part was I had to troubleshoot their code to show the programmer where the compujtation was backwards). Reports that had printed at printer speed (at that time 4 to 10 PPM) started taking several minutes per page (the addition of a logo on the page was the only visible difference and appeared to be the main slowdown).

Shortly after I stopped doing work there, the company was hit with an NRC violation for losing track of some of the waste (the appplication had to track everything in scientific notation and no single atom lost no matter how many times it was combined or converted – but the new app apparently had some rounding errors still in it). The AREV system no doubt still "lives" in one sense – legally it must be maintained for the entire life of the waste that was disposed of.

…the appplication had to track everything in scientific notation and no single atom lost no matter how many times it was combined or converted – but the new app apparently had some rounding errors still in it). The AREV system no doubt still "lives" in one sense – legally it must be maintained for the entire life of the waste that was disposed of.

Must be where we get the notion that Revelation applications have a shelf-life equal to the half-life of plutonium.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I recount the tale of the Girl Guide Association, whose membership database here was run on AREV for many years - which I supported pro bono. And they just spent 12 months trying to commission a VB/SQL replacement system - which takes 3 people 3 days a week to operate.

Or Health Computing Services, whose COBOL payroll and REVG client software (Peruse) ran hospital payrolls here for many years - with REVG handling up to 750,000 payroll history records per file in one case. After they spent millions on a SAP replacement, they found that the processing Window of SAP was all weekend - whereas the turnaround had previously been half an hour per payroll.

Lothar?

Gotta love a bloke in a purple leotard and a mask. Do you still have your magic Phantom ring?

What?

Seem to me a long about the time we arrived here in our present building, we tried to run a universial driver and it would not work.

I don't know if going thru two networks had any thing to do with it or not.

The OI is OpenEngine Ver. 3.7.5 with Vendor/Type IPX/NetWare Multi-User Driver ver. 1.5a.

The Arev is Release Ver. 3.12 with Vender/Type=IPX/Advanced NetWare v1.5a 30 users Max.

I'm running on Novell 3.40.0.0 Windows 98.

They are waiting to update everybody with 2000 PCs.

I have no idea what it's going to take or how much it's going to cost to get what is needed to continue with OI & Arev and still not clash with what everybody else here wants to do.

Old S Bell,

Knee deep need a rope!

As per KB entry on UD 3.0

http://www.revelation.com/knowledge.nsf/ec0a0b99c363fb31852566f50065224a/cbe91c1918f75e3485256d7a00506bb1?OpenDocument

Minimum server for:

Novell - Netware 5.1 SP6 or Netware 6.0 SP3

Windows - NT 4.0 SP6a or Win2K SP1

Will the Universal Driver work with Windows 95/98 workstations?

No, it will only work with NT, 2000 and XP workstations. On networks where you have a mix of NT/2000/XP and 95/98 workstations, if you install the Universal Driver, the 95/98 workstations will not run Revelation-based applications.

My earlier comments referred to the cartoon character "The Phantom". Aaron picked "Lothar" (one of the characters in the cartoon), as Aaron's knowledge of all good things American is encyclopaedic. We weren't having fun at anyone's expense (except ourselves), and we took your posting seriously, Steve.

I guss I'm slow catching on to a lotta changes. A little cartoon logic

may be just what I need.

I'm working with both (Arev/.Net) technologies right now. Basically .Net/ADO/SQL server is very good, but with complex datasets, programming windows forms can be a real pain and take, literally, months to come up with a working form when you are talking about multiple tab pages and datagrids and popups for editing related tables. I'm hoping this will improve substantially with .Net .05 (we are still using .03), but so far, it's a lot more work than MV development. For simple datasets it appears to be much better, and you can indeed point and click your way to a working form, but if you have more than 2 or 3 tables (we have 200 in the SQL database, typically 10 to 30 bound to any one form) in the dataset be prepared for a lot of coding. Once done, it works quite well, but it is a *lot* of work and to make it work well takes a small mountain of code.

Things like lookup tables with the MV world are much easier to handle, so I would say that with complex datasets you will always be able to develop working forms much (much much) faster with OI than .Net. With a simple 2 or 3 table form it would probably be about even.

MV/OI databases strength is rapid development, and I think this will always be true and the more complex the data structure behind the form the more true it is. The power of .Net is that you can do anything in that you can program down to keystrokes and mouse clicks, inherit from windows controls, override most events and extend them, that is both very cool and allows you to develop exactly what is in the specs, it's just a lot of work if the specs aren't something MS has provided a wizard or property for.

I would suggest at least getting your feet wet with VB/.Net OOD and OOP. And don't be scared of the newness, as always when you dig right down through it there's loops and arrays, ifs and elses and you'll be right at home.

As is usual comparing technologies, each has it strengths and weaknesses, knowing what they are is key to choosing the right tool for the job at hand.

hth;

David Craig.

View this thread on the forum...