From: dbenua@panix.com (David Benua)
Subject: Q+E Lib revisited...
Organization: PANIX Public Access Unix, NYC
Date: Thu, 28 Jan 1993 03:08:19 GMT


This thread started here in comp.databases.sybase. I thought
that the answer might be of general interest

>At 10:55 PM 1/26/93 -0500, David Benua wrote:
>>I've been using the Q+E DLLs with Sybase on UNIX for several months.
>>You will need:
>>A copy of DBLIB - W3DBLIB.DLL
>>the netlib for your  TCPIP package  - e.g. WDBFTPTC.DLL or WDBNOVTC.DLL
>>a TCPIP package that supports windows (e.g. LAN Workplace or FTP PC/TCP)
>>
>Is this DLL provided by Sybase?  At what cost?
>

Yes, both W3DBLIB and the NetLibrary (in our case WDBFTPTC.DLL) are 
provided by Sybase. My recollection is that the total cost is about $199
for the pair (single copy). There are, of course, volume discounts.
BTW, QELIB itself lists for around $325, if I'm not mistaken.

>>It works very well. I find that the real advantage is that it can be 
>>called from Macro languages like Excel or Visual Basic. There's not 
>>a great advantage if you're already writing in C.
>>
>Is there an advantage to this product if you are doing C++ and just don't
>want to deal with SQL?  I mean, with the DLLs, you just construct your
>program and don't have to worry about that part of it.
>
>
What do you mean by "just don't want to deal with SQL". You must still
construct SQL statements and pass them to the database with qeSetSQL()
qeAppendSQL() and qeExecSQL(). You must still fetch individual columns 
and rows of your result set with functions like qeFetchNext() and 
qeValCharBuf(). I don't know about you, but I wouldn't call this 
"not dealing with SQL". 

In a C (or C++) environment, there are two advantages to QELIB that I can
think of:
1) Portability. The same (well, nearly the same) code will work on ORACLE,
Sybase, DBase IV, etc. databases. This is a real advantage if you must 
use, for example the Oracle embedded C and Sybase DBLibrary calls. Of course,
being a real C++ programmer, you could just construct appropriate classes
for SQL objects like statements, result rows, data columns, etc. But Pioneer
has done the work for you. 

2) It is a slightly higher level interface than DBLibrary directly. For
example, you don't need to worry about DBProcesses and DBLogins. There is 
only one entity: the Connection. Error handling is also simpler. You can
write a decent error handler which outputs appropriate messages in 
about 10 lines of code.

Whether it's worth it depends on the application. If you don't need 
portability, I'm not sure I'd bother. Look for, (or build) a class library
for those functions you need. If you do need portability, remember that
QE doesn't map the SQL statements. There a number of subtle differences 
in SQL syntax between databases. Usually, simple stuff (SELECT * FROM TABLE1
WHERE ...) will work, but more complex things, like outer joins,
will be handled differently in different databases. 

I hope this helps

Dave B.

 



>Thanks.
>

======================================================
Jeff Gehlhaar           QUALCOMM Incorporated 
jbg@qualcomm.com        San Diego, CA, USA
(619) 597-5241          "The Elegant Solution...."
======================================================


-- 
David Benua                  Internet: dbenua@panix.com 
	                   Compu$erve: 72630,1416
 		
Newsgroups: comp.databases.sybase