Gupta SQLWindows
Ray Theiss
SQLAnyWhere 5.5 DB running on Windows NT.
Can anyone give me any idea how to accomplish this.
Is an ODBC driver necessary ?
Ray Theiss
Leo Tohill
>Is an ODBC driver necessary ?
yes, you need odbc. Run odbadm.exe (not odbad32.exe) to create a 16-bit odbc data source
definition. You may need to install the 16bit version of sqlanywhere before you do this.
Leo Tohill - Team Powersoft
-- Please post in newsgroup, not via email <
Ray Theiss
I do not understand. I cannot find either file on my hard drive, and I have both Windows NT
and Windows 98 installed. Should it/they be located on my drive, or are these files located
on the SQLAnywhere CD.
Also, how do you install the 16 bit version of SQLAnywhere? Is that included on the CD?
Ray Theiss
Leo Tohill
>and Windows 98 installed. Should it/they be located on my drive, or are these files located
>on the SQLAnywhere CD.
>Also, how do you install the 16 bit version of SQLAnywhere? Is that included on the CD?
I'm pretty sure that win95/98/nt come with odbcad32.exe so if it's not there somebody probably
removed it. In any case, if you do a SQL Anywhere/AsA install from the CD it should restore it.
To install 16bit SA on a 32bit machine, run setup from the win16 subdirectory on the install cd.
HTH
Ray Theiss
We're getting closer!
I found the ODBCADM.EXE file. It was located in my Gupta directory. I assume, based on your
previous message, that this is a 16 Bit ODBC Administrator. Using it, I created a ODBC data source,
but I do not understand something.
When setting up the data source, specfically, the "Database Startup" section, I assume that the
"Database File" should point to the "DB" file that I want to accesss. I also assume that I should
stay with the "Custom" radio button. However, the "Options" dialog box confuses me. Should I list
the "DBENG50.EXE" file on the start line; or should I be attempting to execute the client
application. I already have the DBENG50.EXE application running and sitting on the Start Bar, so I
presume that I should not be trying to run it again. Is this correct?
Also, before I received your response, I was attempting to configure a 32 bit data source and was
getting a connection to the SQLAnywhere DB through the SQLWindows application (Well, at least the
SQLWindows application was executing without any error messages, although I was not able to retrieve
any data). Now that I am playing with the 16 bit data source, I keep getting "cannot connect to
database" error messages. Again, could this be caused by running the "engine" as opposed to the
client"?
Finally, your latest response made reference to the "win16" subdirectory on my CD. No such animal!
There is a Win95 subdirectory in the Server directory, however. Is this what you are referring to?
Your comments and suggestions would be greatly appreciated.
Ray Theiss
Jan Eikeland
<reth...@worldnet.att.net> wrote:
>I have to connect a Gupta SQLWindows application (16 bit)
What is Gupta ?
tks
regards
Jan Eikeland
email:jaei...@c2i.net
url :http://home.c2i.net/jaeikela
Ray Theiss
Gupta is the name of a company that makes an RDBMS known as SQLBase.
Ray
Breck Carter
(~1992) the Gupta Windows GUI tool "SQLWindows" ruled the roost. Then
PowerBuilder knocked it off, but the Gupta DBMS "SQLBase" remained a
popular standalone database choice for PB programs; XDB was also
popular. Then Watcom SQL knocked them off too.
Breck The Ancient Historian
Leo Tohill
>"Database File" should point to the "DB" file that I want to accesss. I also assume that I should
>stay with the "Custom" radio button. However, the "Options" dialog box confuses me. Should I list
>the "DBENG50.EXE" file on the start line; or should I be attempting to execute the client
>application. I already have the DBENG50.EXE application running and sitting on the Start Bar, so I
>presume that I should not be trying to run it again. Is this correct?
You should specify dbeng50.exe. When you attempt the connection, if the db engine is already
started, it will not be restarted.
>Also, before I received your response, I was attempting to configure a 32 bit data source and was
>getting a connection to the SQLAnywhere DB through the SQLWindows application (Well, at least the
>SQLWindows application was executing without any error messages, although I was not able to retrieve
>any data). Now that I am playing with the 16 bit data source, I keep getting "cannot connect to
>database" error messages. Again, could this be caused by running the "engine" as opposed to the
>client"?
If sqlwindows is a 16bit product, then I don't think that there's anyway it could have used a 32bit
data source definition.
I'm assuming that you are running the standalone engine in which case you don't need to run the
dbclient.exe (or the 16bit dbclienw.exe).
But let me back up a bit. When running a 16bit app you can either:
use a 16bit data source definition and the 16 bit engine dbeng50w.exe and thus have a purely 16bit
solution.
or
use odbc to cross the 16-32 divide, allowing your 16bit application to use the 32 bit engine. You
can do this by defining the same data source name to both the 16 bit and 32bit odbc managers. When
you do this, MS-Windows "thunks" your applications calls to the 16 bit driver over to the 32bit
driver. The 32bit driver in turn uses the 32bit SA engine.
This is rather complex so ask again if you need clarification.
If you are using server engine (dbsrvxx.exe) let me know and I'll try to remember how it handles
16x32.
>Finally, your latest response made reference to the "win16" subdirectory on my CD. No such animal!
>There is a Win95 subdirectory in the Server directory, however. Is this what you are referring to?
Sorry, the directory is named "Windows". The other dirs are Dos, OS2, Win95, and Winnt.
Paul A. Horan
What _actually_ killed off SQLWindows was Umang Gupta demanding to put his
own face all over the product's print ads.... Frightened off all the
customers! <G>
Paul Horan
Breck Carter wrote in message <367d16c5...@forums.sybase.com>...
Breck Carter
programmers named Gupta. This fact once prompted Mitchell Kertzmann to
consider obtaining photographs of Umang Gupta plus 9 like-named PB
programmers for his own ad:
"Nine out of ten Guptas prefer PowerBuilder!"
Breck
Raymond Theiss
Perhaps I need to understand some basics.
When I started this thread, I was using my home machine, which runs NT Workstation 4.0 with Service Pack
3. I installed the databse server and it operated fine, I set up the ODBC drivers, both 32 and 16 bit,
and I was able to establish a connection through Microsoft Access without any problem.
I have now come to the office and tried it and I am having problems.
Here at the office, I have NT Server with Service Pack 3. I installed SQLAnywhere 5.5, created a databse
and I tried to connect to the DB from a Win '98 client. On the client, I installed SQLAnywhere
Professional Client and I set up the ODBC data source (which, of course, may be the heart of the
problem).
Using SQL Central, I cannot see or connect to the DB. When I attempt to connect, I get an error message
stating: "Unable to start specified database".
The DSN in the ODBC Administrator specifies the location of the DB on the server in the "Database FIle"
field; the "Custom" button is checked; the "Start Command" under "Options" specifies "DBENG50.EXE"
running on the server; the UserID and Password are "DBA" and "SQL", respectively.
Before I venture into attempting to connect SQLWindows in this environment, I think I should be able to
use SQLCentral or Microsoft Access.
Is there anything about this setup which is suspect.
Please advise.
Ray Theiss
Leo Tohill
>Professional Client and I set up the ODBC data source (which, of course, may be the heart of the
>problem).
>Using SQL Central, I cannot see or connect to the DB. When I attempt to connect, I get an error message
>stating: "Unable to start specified database".
Sybase central does not use ODBC, so we can eliminate that consideration from the picture at this
point. (We can also eliminate the 16bit issue, for the moment. )
Try this:
1) start the server engine, specifiying the database file that it is to serve, e.g.,
DBSRV50 -c 32m c:\db\mydb.db
This starts an engine named "mydb" serving a db named "mydb". It allows all protocols.
2) at the client, try running dbclient.exe from the command line as
DBCLIENT mydb
If this succeeds, go to step 3. If it fails, let's discuss why. Probable cause: protocol iissues.
3) at the client, start sybase central . Open the connection dialogue and specify uid, pwd, and
server name = "mydb", and database name = "mydb". Since dbclient is already running, this should
succeed. If it doesn't... recheck your connection parameters.
4) At the client, you should have an 32bit odbc data source that specifies start command =
dbclient.exe. Leave the db switches empty. Attempt a connection from a 32bit application using
this data source. It should succeed.
5) If you like, create at the client a 16bit odbc data source just like the 32bit one - same name.
Attempt to connect from a 16bit application. It "should" succeed.
Now, try the above without step 2. to wit:
1) same as above.
2) skip
3) when connecting from sybase central, also click the "Network" option in the connection dialogue.
4) same as above. SInce, if step 3 succeeded, the client is already running, this step should
behave the same as in the first scenario.
Finally, try this:
1) same as above.
2) skip
3) skip
4) same as above. In this case the odbc connection will be starting dbclient.exe. Let's see if
this works.
We'll get to the bottom of this!
Raymond Theiss
You are a God-send. Your advice is thorough, succintn and greatly appreciated!
Most things worked fine. The one thing that did not work was the selection of "Network" in the options
section of the connection dialog box. I have to use the "Custom" radio button and specify "dbclient
<DBNAME>" on the start line. Nevertheless, I am able to connect directly from Microsoft Access (32 bit
application) via ODBC, without starting DBCLIENT directly.
In addition, I am able to connect my SQLWindows application to the DB via the 16 bit ODBC driver that you
suggested I create. Which, after all, is my ultimate goal.
A couple of ancillary questions:
1. When starting the database server, I notice that TCP/IP, IPX and other protocols are loaded. Is this
necessary or desirable. I have a TCP/IP Windows NT network. Can I restrict the DB to one protocol?
2. How can I move a database from one machine to another. Specifically, while I was tinkering this weekend,
I created a database at home, with the structure of the database from the office. I then copied the "DB"
file, together with its log file to a disk, took it to the office and placed them both into the appropriate
directory. When I try to start the DB, I get a "Cannot read log file" error message. Is there any way that
I can transport this DB from home to the office?
Thanks a million for all of your help!
Ray Theiss
Leo Tohill
>necessary or desirable. I have a TCP/IP Windows NT network. Can I restrict the DB to one protocol?
Yes, see the -x parameter of dbsrv50. e.g.,
dbsrv50 -x tcpip ...
>2. How can I move a database from one machine to another. Specifically, while I was tinkering this weekend,
>I created a database at home, with the structure of the database from the office. I then copied the "DB"
>file, together with its log file to a disk, took it to the office and placed them both into the appropriate
>directory. When I try to start the DB, I get a "Cannot read log file" error message. Is there any way that
>I can transport this DB from home to the office?
Run "dblog yourdb.db" and see how the log file is specified. For convenience you could just
specify the log file without a path, in which case it will be kept in the same directory as the db.
You've probably specified some other directory that is not available on one of the machines.
>You are a God-send. Your advice is thorough, succintn and greatly appreciated!
Woud you cc: my mother on this? <g>