Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SQLWindows 5.0.2 and ODBC (again)

51 views
Skip to first unread message

Weiqi Gao

unread,
Apr 5, 1996, 3:00:00 AM4/5/96
to
During the past six months I've posted articles about the errors I get
when I use SQLWindows 5.0.2/SQLBase 6.0.0 (from the SQLWindows 5.0.2
CD) with ODBC (Driver from the SQLBase 6.0.0 Diskettes.)

The errors I have encountered include "Your don't have a license" (I
do), "Driver not capable" (no problem last time), "sqlodbw: Can't
communicate with the ODBC", "401", Garbage in the SQLBase ODBC login
dialog box's Database combo box, etc.

Yesterday, I finally did a windows clean-up
C:\>DELTREE \WINDOWS [ENTER] ; fun, fun, fun ...
on my machine and reinstalled everything (gotten rid of at least 100MB
of dlls.)

Now everything worked (after deleting several files from the C:\GUPTA
directory that are duplicated in the C:\SQLBASE directory), except
that I can't goto an SQLBase ODBC data source from Quest (Error number
20055, which is mapped to S1000 in ODBC---General error.) I also get
a (seemingly) harmless message "Two databases named "Gupta" are found,
only the first one is used by Quest".

My question: is it theoretically possible --OR-- is it theoretically
impossible to go from Quest to a SQLBase databaase through ODBC (all
on the same local machine)? I ask because MS Access can't open an
Access file through ODBC.

It'll be nice if I can get rid of the "two Guptas found" message.

--
Weiqi Gao
weiq...@crl.com


Patricia Warwick

unread,
Apr 6, 1996, 3:00:00 AM4/6/96
to
In article <4k4afp$k...@nntp.crl.com>, weiq...@crl.com (Weiqi Gao) wrote:
<snip>

>My question: is it theoretically possible --OR-- is it theoretically
>impossible to go from Quest to a SQLBase databaase through ODBC (all
>on the same local machine)? I ask because MS Access can't open an
>Access file through ODBC.
>
If I understand your question correctly, the answer is NO. It is not possible
to go from Quest (or SQLWindows) through ODBC, since Quest issues SQL/API
calls and they would have to be translated into ODBC calls in order to use
ODBC, and then translated back into SQL/API to be understood by SQLBase.
Gupta/Centura Software provides drivers that translate the SQL/API into ODBC
in order to talk to ODBC datasources, and we also provide a translator from
ODBC to SQL/API in order that tools such as Visual Basic can access SQLBase
using ODBC interface. But the two ODBC drivers can't be used together.


!
! Patricia Warwick
! Senior Consultant
! Centura Professional Services
!

Weiqi Gao

unread,
Apr 8, 1996, 3:00:00 AM4/8/96
to
weiq...@crl.com (Weiqi Gao) wrote:

>During the past six months I've posted articles about the errors I get
>when I use SQLWindows 5.0.2/SQLBase 6.0.0 (from the SQLWindows 5.0.2
>CD) with ODBC (Driver from the SQLBase 6.0.0 Diskettes.)

>The errors I have encountered include "Your don't have a license" (I
>do), "Driver not capable" (no problem last time), "sqlodbw: Can't
>communicate with the ODBC", "401", Garbage in the SQLBase ODBC login
>dialog box's Database combo box, etc.

>Yesterday, I finally did a windows clean-up
> C:\>DELTREE \WINDOWS [ENTER] ; fun, fun, fun ...
>on my machine and reinstalled everything (gotten rid of at least 100MB
>of dlls.)

>Now everything worked (after deleting several files from the C:\GUPTA
>directory that are duplicated in the C:\SQLBASE directory), except
>that I can't goto an SQLBase ODBC data source from Quest (Error number
>20055, which is mapped to S1000 in ODBC---General error.) I also get
>a (seemingly) harmless message "Two databases named "Gupta" are found,
>only the first one is used by Quest".

>My question: is it theoretically possible --OR-- is it theoretically


>impossible to go from Quest to a SQLBase databaase through ODBC (all
>on the same local machine)? I ask because MS Access can't open an
>Access file through ODBC.

>It'll be nice if I can get rid of the "two Guptas found" message.

The "Two Guptas" message is caused by me specifying "SERVER2" in the
"Server..." dialog off the Utilities|Databases|Add... screen.
Apparantly, the local engine count as a server.

--
Weiqi Gao
weiq...@crl.com


Ales Jeglic

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to weiq...@crl.com

All SQL/API calls are perfromed via SQLAPIW.DLL as mentioned in
documentation. Like this:

Application --> SQLAPIW.DLL --> SQLODBW.DLL --> SQLBAse ODBC driver


But GUPTA SQLBase ODBC drivers also need SQLAPIW.DLL to perform SQL
requests to the server via any of possible protocols:

SQLBase ODBC driver --> SQLAPIW.DLL --> SQLSPXW.DLL --> Network drivers

In this case SQLAPIW will be entered reentrantly and this DLL is not
reentrant (as documented somwhere I remember !).
So I think that such recursive experiment is not possible.

About GUPTA SQLBase ODBC driver, did you have SQLAPIW.DLL on DOS PATH
at ODBC instalation time ?

Weiqi Gao

unread,
Apr 10, 1996, 3:00:00 AM4/10/96
to
Ales Jeglic <Al...@mc-ii.si> wrote:

>All SQL/API calls are perfromed via SQLAPIW.DLL as mentioned in
>documentation. Like this:
> Application --> SQLAPIW.DLL --> SQLODBW.DLL --> SQLBAse ODBC driver
>But GUPTA SQLBase ODBC drivers also need SQLAPIW.DLL to perform SQL
>requests to the server via any of possible protocols:
> SQLBase ODBC driver --> SQLAPIW.DLL --> SQLSPXW.DLL --> Network drivers
>In this case SQLAPIW will be entered reentrantly and this DLL is not
>reentrant (as documented somwhere I remember !).
>So I think that such recursive experiment is not possible.

Thank you for the explanation. I now have everything working.

>About GUPTA SQLBase ODBC driver, did you have SQLAPIW.DLL on DOS PATH
>at ODBC instalation time ?

Yes, I did have SQLAPIW.DLL on my DOS PATH when I installed the ODBC
Driver.

After comparing three installations of SQLWindows/SQLBase combination,
I discovered that all of my past ODBC problems can be blamed on one
reason: version mismatch. This can happen at several places:

1. When installing SQLWindows/SQLBase. As mentioned above, the files
SQLAPIW.DLL (and SQLWSV.DLL [or other comdlls] and DBWSERVR.EXE) are
used by SQLWindows --AND-- SQLBase. If I installed SQLWindows
5.0.0/1/2 with the local database engine option, and then installed
SQLBase 6.0.0, I will have multiple versions of these three files on
my system. Depending on whether C:\GUPTA comes before C:\SQLBASE or
after it, a different one is loaded each time.

My solution to this problem: after installation, do a
CD C:\TEMP
DIR /B C:\GUPTA > GUPTA.DIR
DIR /B C:\SQLBASE > SQLBASE.DIR
COMM -12 GUPTA.DIR SQLBASE.DIR > DUPLICAT.DIR (This is the GNU comm)
and delete everything that appeared in the duplicates list from the
C:\GUPTA directory (they are the SQLBase 5.2.x files)

2. When installing the SQLBase ODBC Driver. It simply installs older
version of the ODBC Driver Manager files into the C:\WINDOWS\SYSTEM
directory. In the past, I solved this problem by reinstalling MS
Access 2.0 (I still don't know why it worked.)

Later on, I've discovered the "Advanced" options in the SQLBase ODBC
driver installation screen, where I can specify "Do not install Driver
Manager" and "Do not install translation files".

3. The file SQLODBW.DLL, although specified in the client sql.ini file
in the comdll section, is not in the SQLBase package (like the other
comdlls do.) This is logical, because is is used only by SQLWindows
applications. What I've found out is that this file is fairly
independent of the Gupta stuff.

For example, I can use the SQLODBW.DLL from 5.0.2 with 5.0.1 and 5.0.0
with good results. The later version fixes bugs in earlier versions.

--
Weiqi Gao
weiq...@crl.com


gu...@ozemail.com.au

unread,
Apr 11, 1996, 3:00:00 AM4/11/96
to
weiq...@crl.com (Weiqi Gao) wrote:

>During the past six months I've posted articles about the errors I get
>when I use SQLWindows 5.0.2/SQLBase 6.0.0 (from the SQLWindows 5.0.2
>CD) with ODBC (Driver from the SQLBase 6.0.0 Diskettes.)

>The errors I have encountered include "Your don't have a license" (I
>do), "Driver not capable" (no problem last time), "sqlodbw: Can't
>communicate with the ODBC", "401", Garbage in the SQLBase ODBC login
>dialog box's Database combo box, etc.

>Yesterday, I finally did a windows clean-up
> C:\>DELTREE \WINDOWS [ENTER] ; fun, fun, fun ...
>on my machine and reinstalled everything (gotten rid of at least 100MB
>of dlls.)

>Now everything worked (after deleting several files from the C:\GUPTA
>directory that are duplicated in the C:\SQLBASE directory), except
>that I can't goto an SQLBase ODBC data source from Quest (Error number
>20055, which is mapped to S1000 in ODBC---General error.) I also get
>a (seemingly) harmless message "Two databases named "Gupta" are found,
>only the first one is used by Quest".

>My question: is it theoretically possible --OR-- is it theoretically
>impossible to go from Quest to a SQLBase databaase through ODBC (all
>on the same local machine)? I ask because MS Access can't open an
>Access file through ODBC.

>It'll be nice if I can get rid of the "two Guptas found" message.

>--
>Weiqi Gao
>weiq...@crl.com

Weiqi,

The current SQL API supplied with Gupta products does not support
re-entry into the API. Since SQLWindows/Quest uses the same
sqlapiw.dll as the SQLBase ODBC driver, they try to access the same
API. Therefore, this type of setup is not possible.

Keith Remmes
Gupta Australia


0 new messages