How did you get started using RES-Reach?
I got a job here right out of college. I had seen RES-Reach briefly at the college, and some other products too, but I only started using it here. It's a significant intranet project where I'm mostly working alone.

So how does RES-Reach compare with similar products you've seen?
I guess I'd sum it up by saying it's elegant and simple to use. With most other products you have to work with lots of new tags, and learn lots of syntax, you have to learn a whole new language to embed inside html and sometimes use two, three different languages with conflicting syntax simultaneously in one file. Some make you keep two or three files with different extensions in synch. They do things like hiding their code inside comments or in a bunch of separate files, or blatantly breaking the rules of sgml/html. They're trying to stuff procedural code into a declarative language. The reach language is just html with a couple of extra paired tags. I tried a couple of other products and I got stuck right away trying to create a DSN.

A DSN?
A "Data Source Name". It's where you tell the server in advance about a database that you intend to open in the future, and go through a configuration process, and give it a new name. You do this for each database you might want to query. Now, call me an idiot if you want but I could never get those things right the first time, and if you used the wrong kind of DSN or you change the version of the driver or you just change your mind about some detail later, you start over. It's back to the server and then things that used to work stop working. And you can't just install your application on a different machine. You have to set up all the DSNs the same way again.

With RES-Reach on the other hand you just tell it the type of database and directory name, or whatever way you normally refer to that type of database, and you're in business. No DSN. I can even do it dynamically. This user goes to this database and that user goes to that database. I can create brand new databases within the program and immediately query them. I can create a custom dBASE file in the user's download directory and I don't even have a copy of the dBASE language! But what I normally do is leave it blank and it defaults to MS Access.

Which version of Access? 2, 95, 98?
All of them. Any of them. In some cases I query several databases that use different versions within the same page. It figures out the details by itself.

How easy is it to use RES-Reach?
Installation was so easy I thought I'd done something wrong. It installs a component as an NT service so it's always ready to go. At one point I had two different Web servers and a bunch of different executable directories, and different permissions on copies of the "exe" file. It took it all in stride. The language itself is simple to learn. It's just html with 3 extra paired tags. There's an "if" tag, with a matching end tag. The "data" tag runs SQL queries, and the "record" tag iterates through sets of records. Then I use whatever the web lets me use, but it's all dynamically generated: the JavaScript, the applet parameters, the style sheets, whatever.

I'm always looking up html and JavaScript and server manuals, but I've barely opened the RES-Reach manual since the first week.

So besides simplicity what are the important features?
I would say nesting, nesting, and nesting. For a simple example, say I want to produce a report that shows what each student has done in a semester. I query the teacher profile based on her login. That's a recordset of one or zero records at the top level. Nested within that, I query for the list of students in her classes. That's the second level, and there are maybe 25 records. Nested at level 3 is a query that lists the activities of that student, and so on. I can do this with any database, not just those that implement "cursors". That nesting has a lot of benefits. I can write re-usable components that are called from various pages with different contexts, I can do recursion, and I can avoid writing complicated join queries that I can't figure out afterwards. I can even do joins and other operations between say, an Oracle and a Paradox file.

Isn't that slower than a single join query?
Possibly, I'm not sure, but I'm not forced to write code I can't understand. I can do the join in one query, or I can nest another query. But if you want to talk about speed, this thing is really fast. I tried to benchmark it once to see if an intranet application would be much slower than the native database language over a LAN. Well guess what? It was faster than using the database straight.

If you have lots of concurrent users, well, it's multithreading. You can have lots of instances running absolutely concurrently. They don't queue, they're actually simultaneous. If you've got the memory and the processors, then it just keeps on speeding up.

What about security aspects?
In this application, I restrict access and depending on who you are, you get different queries, different databases, different programs. I have my own development environment where I try things out and a training environment for new users. I can run all of them simultaneously on a single single copy of the software. The RES-Reach service runs under its own account, and I can set permissions so that only this account can read the program files and the databases. A hacker coming in over the internet, even if they're authenticated, can't see any of these files. In other languages, I have to be very careful with permisons and mis-spelled file names thatescape access control, because all your source code is sitting right there in a Web-accessible directory, and the entire world has read access, and I have to give the world full access to my database. With RES-Reach the outside world can just request that a program be executed by the RES-Reach account, but they can't get near my code or my databases.

Would you recommend it for simple or more complex applications?
Can I say both? I mean, it's flexible enough for either one. I personally like the fact that I have full control. If I want to use a raw http header, I can. If the latest Microsoft browser makes information available to the server, like the display settings of your computer or whether the user has installed some funky new file format, it's right there for me to use. If they invent some new feature like when they change the cookies spec, I can go right in without waiting for a new release. I can do OFX [Open Financial Exchange: Ed.] and XML [Extended Markup Language: Ed.] right now and they're hardly invented them yet. It's not all hidden in some object or method that somebody might implement some day. But if I don't want to know all about http headers and stuff, I don't need to know it exists.

I really recommend it. Writing web applications is tough enough because you spend so much time fighting browser incompatibilities. For me, RES-Reach was the least troublesome part of writing for the web.