On Sunday, September 13, 1992 at 12:02:38 PM UTC-7, [email protected] wrote:

In article <[email protected]> [email protected] (Raymond Petersen) writes:

In article <[email protected]> [email protected] (ThomasD.Gasser) writes:
[munch]
4) The part that I use most is Embedded SQL (in my C code). I then use a
pre-processor which converts the SQL in my C code to C function calls that are resolved at link time by library that comes in the developer's edition. (It comes with Borland,Microsoft,and WATCOM C compilers. If you need it for another compiler - ask.) The one thing that some people may find unusual is that in WATCOM SQL all Embedded Sql is dynamic. None of it is precompiled, it is only pre-processed. There are a LOT of advantages to doing it this way. The reason most products precompile SQL into a PLAN table, is execution speed, but lack of speed isn't one of WATCOM SQLs shortcomings.

This is NOT unusual. In fact, with the exception of IBM's and DEC's precompilers for DB2, SQL/DS and RDB, most of the SQL engines that
have precompilers use dynamic SQL for execution (i.e., they pass
the SQL statement as a string from the program at execution time).
Sybase supports stored procedures but no precompiler (that may have
changed recently but I am not sure whether the precompiler uses
the stored procedures). For most SQL engines, "static" SQL is
just a precompiled cover on dynamic SQL.
The reason that *some* products (like DB2 and RDB) precompile SQL
is because the cost of optimizing large queries (particularly
multi-way joins) at execution time can be very high. Doing it
once at precompile (or bind) time is much cheaper in machine
resources and also permits the optimizer to investigate far more
potential choices than a run-time optimizer can if you expect it
to be responsive. All of this depends on how complex your queries
are and how big your databases are. Any PC-based database is
going to be relatively small (maybe tens of megabytes or so)
compared to mainframe and large server databases of gigabytes
and upwards. What you consider good speed on a "large" (your
view) database of 50,000 rows will degenerate rapidly on a
truly large database of 50,000,000 rows. At that point, the
more time an optimizer has, the more likely it is to find the
best and fastest path through the query.

[munch]
- ANSI standard SQL transaction logs

Huh? ANSI provides no standard for SQL transaction logs that I
know of. Is this a claim of the software vendor or your editorial
commentary? Inquiring minds wish to know :-)

- Transaction processing with a checkpoint log and a forward transaction log
- Comprehensive security capabilities
- Updatable views
- Easily imports data files from other popular data formats.
- Automatically uses expanded and extended memory to improve performance
- Will run on 640K PCs (I do)
- Royalty free run-time - $99.

6) Other interesting facts.
a) All strings are variable length.

This is not a feature I consider good. Specifically, it must impact performance in SOME way to not have fixed length strings when varchars
are unnecessary. Why is it that practically no one gets this right?

b) NULL values in a row only use 1 bit to store.

I assume you mean 1 bit per field. This is common but limiting if
you ever want to support multi-valued NULLs (ala SQL2) or have other
uses for a column-oriented flag. I prefer at least 2 bits per column.

c) The developers spent a lot of time comparing the speed of WATCOM SQL (the 386 database engine) and Microsoft SQL Server, so that their product would outperform Microsoft's on the most common operations.

Not very difficult, IMHO :-) I would be more interested in how they
compare to Oracle System 7.
Jon Rosen

4

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 10, 1992 at 7:31:11 PM UTC-7, Raymond Petersen wrote:

In article <[email protected]> [email protected] (ThomasD.Gasser) writes:

Ok every one, I am looking for opinions on WATCOM's SQL database server for >Novell. The price seems right ($395for the developers version and $95 to >upgrade to the 6 user network version). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since I have a lot of experience with this product (I used the first version before it was shrink-wrapped and beta tested the new version that they released)

I'll post a summary of this product.
1) I consider the major strength of WATCOM SQL to be the speed of retrieving data. I've tested most DOS and one OS/2 SQL DBMSs and WATCOM SQL has outperformed them all (for speed). From my tests I would say that
cost-based optimizing heuristic is VERY good - even when compared to programable filers like Dbase, FoxPro, and Paradox.
2) The core parts of the database package are the engine (that runs as a 235,000
byte TSR for a single user) and ISQL (which allows you to type interactive SQL statements. It also can import data from Dbase files etc.) If you are running on the LAN, then the engine runs on the dedicated database server (They suggest that you use the 386 protected mode engine - which uses 100K of real memory and an additional 700K of expanded memory.) and the client TSR runs on all the client machines. The memory usage of the client TSR can be adjusted from 110,000 bytes to 70,000 bytes by using command line parms.
By the way, one of the major reasons we began using WATCOM SQL was that the single user database engine was 128,000 bytes smaller than the previous DOS SQL DBMS that we were using. (Not to mention that it was 5 times faster on complex SQL queries).
3) The product comes with a 4GL called ACME (Application Creation Made Easy) It is quite tightly integrated with the database engine and it is quite simple to get an application that uses the database up and running.
However, like any 4GL it forces you to conform to its paradigm.
(It seems that C programmers like myself are irked by this restriction on
our freedom and only use 4GLs for a certain style of application.)
4) The part that I use most is Embedded SQL (in my C code). I then use a pre-processor which converts the SQL in my C code to C function calls that are resolved at link time by a library that comes in the developer's edition. (It comes with Borland,Microsoft, and WATCOM C compilers. If you need it for another compiler - ask.) The one thing that some people may find unusual is that in WATCOM SQL all Embedded Sql is dynamic. None of it is precompiled,
it is only pre-processed. There are a LOT of advantages to doing it this
way. The reason most products precompile SQL into a PLAN table, is
execution speed, but lack of speed isn't one of WATCOM SQLs shortcomings.
5) Here is their list of features (sent to WATCOM C registered users)
- ANSI standard SQL
- Bi-directional scrollable updatable cursors
- Referential and entity integrity
- Automatic Query optimization
- Row-level locking
- Symmetric multi-threading of LAN server requests.
- Database compression
- Database encryption
- ANSI standard SQL transaction logs
- Transaction processing with a checkpoint log and a forward transaction log - Comprehensive security capabilities
- Updatable views
- Easily imports data files from other popular data formats.
- Automatically uses expanded and extended memory to improve performance
- Will run on 640K PCs (I do)
- Royalty free run-time - $99.
6) Other interesting facts.
a) All strings are variable length.
b) NULL values in a row only use 1 bit to store.
c) The developers spent a lot of time comparing the speed of WATCOM SQL
(the 386 database engine) and Microsoft SQL Server, so that their product would outperform Microsoft's on the most common operations.
If you have further questions I'll try to answer them (as long as I don't get too many)
I have no connection with WATCOM other than as a satisfied customer and beta tester.
Customary warnings that I don't speak for my employer apply.
Raymond Petersen
MicroComputer Centre
Mutual Life of Canada

The program is still a real powerful tool today.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)