SQL Anywhere Setup
Jason Clevenger
I am trying to configure an ODBC data source for a new SQL Anywhere
database created on my local hard drive. This is the first time
I'm using a local database (Our shop DB is on the network). I've tried
to do this both with SQLAnywhere's ISQL and from the PowerBuilder
development tool. I get the following error when I do this.
The setup routines for the Sybase SQL Anywhere 5.0 ODBC driver could not
be loaded. You may be low on memory and need to quit a few applications.
I have 16 MB on a pentium, WIN 3.51, PB 5.002. I've tried closing
every application, restarting the machine etc. I can't quite believe
that I am low on memory. One possibilty might be the maximum program size
allowed under conventional DOS. Does anyone know if this is an issue for
SQL Anywhere or have any other suggestions?
Best
Jason Clevenger
Steve hood
Jason Clevenger <ja...@cfs-cf01.wustl.edu> wrote in article
<5k2v90$aes$1...@newsreader.wustl.edu>...
> The setup routines for the Sybase SQL Anywhere 5.0 ODBC driver could not
> be loaded. You may be low on memory and need to quit a few applications.
> Jason Clevenger
>
>
It's been my experience that it's one of the following
1. The reference to sqlany on the dos path is incorrect.
2. The reference to sqlany on the dos path must be near the front of the
path statement. If you have a large path and it is was appended to the end,
move it near the front. On a Novell network, the search drive mappings get
inserted at the front of your path (i.e before your local drives), so this
could be pushing it even further along the path than you realize. If you
are using alot of network search drives and/or those search drives
themselves have long paths (ie. deep directory structures), you may need to
lose some of them OR make sure they are mapped as ROOT drives.
Jeff A Kinsey
i have seen SQL Anywhere trunc ODBC info in ODBC.INI and ODBCINST.INI
also, it takes one set of 'drivers' for standalone another for network.
-jeff
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"life is a beach... find one and enjoy it!" -jeff a. kinsey
mail: jki...@world.std.com | http://world.std.com/~jkinsey/
Bryan McLennon
hey---
That's mah favorite. It just means one of a million(+- 10000) problems are present.
(I've never run into anyone that actually had a memory problem - then again, this is an
MS message)
Basically, it means that somewhere in the process of loading ODBC something failed. For
5.5.00+ you get a few messages more than the typical 5.0.02 user would.
To follow the basic hip-bone is connected to the thighbone rules, bend an ear (or eye)
to the follwing -
Yer basic 16 bit app calls odbc.dll
Yer basic 32 bit app calls odbc32.dll
(Note for 16 bit apps running under 32 bit OS (NT/95) they still call odbc.dll)
Yer basic 16 bit ODBC.dll opens ODBC.ini (regardless of O/S it's running under -
3.1,NT,95,99,2005,etc.). IF it finds a DRIVER32= line under [datasourcename] AND it's
running under NT/95 it loads the 32 bit driver (WOD50T.dll), otherwise it looks for a
DRIVER= line and loads that 16 bit driver (WOD50W.dll).
Yer basic 32 bit ODBC32.dll is already running under NT/95 (don't mess with me and
Win32S under 3.1, it doesn't work unless yer facing south at sunrise on a solstice
(winter or summer, it's not particular) and you've done something unmentionable with yer
Sybase rep).
ODBC32.dll looks in the registry under
HKEY_Current_user/Software/ODBC/ODBC.ini/{datasourcename} and if it finds this key and
DRIVER= under it, it loads that 32 bit driver.
If we're under a 16 bit system, yerApp loaded WOD50W.dll.
If we're under a 32 bit system, running a 16 bit app, yerApp loaded WOD50W.dll.
If we're under a 32 bit system, running a 32 bit app, yerApp loaded WOD50T.dll.
OKay, for people who have loaded WOD50W.dll, this dll looks in the path for WLEN50.dll -
"language dll",
For people who have loaded WOD50T.dll, this dll looks in the path for WLEN50T.dll (also
known to the cognescenti as the "languange dll").
(In case your logical sensibilities have reasoned that I must have ment WLEN50W.dll
instead of WLEN50.dll when called from WOD50W.dll, I applaud you (and me), but not
Sybase - the naming convention is predictable, but not simply so. the 16 bit language
dll IS WLEN50.dll. In general, T at the end of a module name means 32 bit, and W at the
end means 16 bit except for the language dll).
The language DLL contains error, warning and informational messages and is used by most
SQL Anywhere executables and dlls.
Now the database must converse with the database so it loads DBL50T.dll or DBL50W.dll,
known to masons who give the correct sign (or read the manuals) as the database
interface.( Identifying the 32 bit versus the 16 bit version is left to the user as an
exercise). Make sure that the right one is in the path.
If yerApp has to start the database (or client) since it can't find something already
running on your own machine, it looks at the START= line in the ODBC.ini file/registry.
If it refers to a network database, the start line should refer to DBCLiENT (32 bit
connection) or DBCLIENW (16 bit applications). If you are expecting to start a local
database, "databasefile=" should be specified and START=should reference "dbeng50".
However, problems with the START= line do not (normally) result in the "shut down a few
of yer apps" message.
Basically, if ODBC is installed (bunch o' ODBC*.* modules in yer WIN\SYSTEM,
WINNT\SYSTEM, WIN95\SYSTEM), and the sqlany50\win and/or sqlany50\win32 directory is in
the path, everything should work.
Look for mulitiple versions of the driver (WOD50T/W.dll), the language dll
(WLEN50T/.dll) and the . Earlier versions of ODBC/SA gave no clues as to the problem
(hey buckaroo, yer out of memory er sumptin) but later ones sometimes spew out
"mismatched language dll" messages.
A problem could have occurred (particularly with the language dll) if you installed the
standalone over your client installation. If the standalone (dbeng50w/dbeng50t) is of a
later date from your client
(dbclient/dbclienw,wod50t/wod50w,wlen50t/wlen50,dbl50t.dll/dbl50w.dll) installation, the
standalone will vomit this message.
If you haven't reinstalled from the original cd to the target machine, do so. This cures
most problems. Try ripping out everything starting with ODBC* in the system directory
EXCEPT odbc.dll and odbcinst.dll and reinstalling.
I think 5.0.02 fixed an install problem on Win95 (not NT) machines, but it might have
been 5.0.03. If you installed 32 bit over 16 bit, two 32 bit Win32S stubs (ODBC32.dll
and ODBCINST.dll) that were under 20k were left instead of being replace with the "real"
WIN32 versions (both over 60k). Check these little buggers. If they're under 20k, delete
them and reinstall (or get the real versions of ODBC32.dll and ODBCINST.dll elsewhere).
This doesnt normally apply to NT because nt stores 16 stuff in WINNT\SYSTEM and 32 bit
stuff in WINNT\SYSTEM32.
To analyse the difference between your net access and your local access, I'd look at the
ODBC.ini file or (for 32 bit apps, or 16 bit data sources that specify DRIVER32= in the
ODBC.ini file) the registry entry HKEY_Local_User/Software/ODBC/ODBC.ini/yerDataSource
the entry under driver= and make sure it's the same with your net apps.
Good luck!
If you like the advice, email me, if you don't, flame me in every newsgroup - I can use
the publicity.
Bryan McLennon
Intuitive Computer Systems Ltd.
mcle...@sympatico.ns.ca
>
> I am trying to configure an ODBC data source for a new SQL Anywhere
> database created on my local hard drive. This is the first time
> I'm using a local database (Our shop DB is on the network). I've tried
> to do this both with SQLAnywhere's ISQL and from the PowerBuilder
> development tool. I get the following error when I do this.
>
> The setup routines for the Sybase SQL Anywhere 5.0 ODBC driver could not
> be loaded. You may be low on memory and need to quit a few applications.
>
> I have 16 MB on a pentium, WIN 3.51, PB 5.002. I've tried closing
> every application, restarting the machine etc. I can't quite believe
> that I am low on memory. One possibilty might be the maximum program size
> allowed under conventional DOS. Does anyone know if this is an issue for
> SQL Anywhere or have any other suggestions?
>
> Best
>
> Jason Clevengerte