| Hi Renee,
I assume you mean running concurrently on the windows platform, huh? DLLs on
windows 3.1 were shared everything (code and data). This is why problems
could occur if you tried to run multiple copies of the SQL/Services client.
One client could write DLL data and have it overwritten by another client.
This is still the case with the SQL/Services Windows 3.1 client.
On NT and Windows 95, DLL data is copy on write. When a SQL/Services client
writes DLL data, it writes to its own copy. So on these platforms, multiple
instances of SQL/Services clients will not interfere with each other.
Sue
|
| Well let me get more specific then...
The customer is running on NT 4.0 and is trying to use MS IIS to create
concurrent access to the web in order to access an Rdb database. He has
this working for a single process, but when he starts using concurrent access
ODBC falls apart with WSAEINPROGRESS errors. When I looked up these errors
in STARS, it indicated that SQL/Services only supported single stream access.
If this isn't true for NT and Win95, anyone have any idea why concurrent access
would fall apart?
Cuatomer is running 2.10.11 of ODBC and 6.0-02 of SQL/Services.
Thanks,
Renee
|
| Hi Renee,
I'm not familiar with MS IIS, so I don't know how it does concurrent access.
Does it run multiple processes, or multiple threads in one process?
We have run multiple SQL/Services applications (i.e. multiple processes)
concurrently on NT and Windows 95 with no problems. We have also run
multithreaded SQL/Services applications on NT and Windows 95 with no
problems.
There's only one way we can think of that SQL/Services can be causing the
WSAEINPROGRESS errors. WSAEINPROGRESS means:
A blocking operation is currently executing.
Windows Sockets only allows a single blocking operation
to be outstanding per task (or thread), and if any other
function call is made (whether or not it references that
or any other socket) the function fails.
SQL/Services has synchronization code to prevent a child thread from doing
I/O when the main thread or another child thread is already doing I/O. This
should prevent the WSAEINPROGRESS error. You may run into this problem with
SQL/Services if a child thread starts a network I/O, and then the main thread
attempts to start a network I/O. For performance reasons, the
synchronization code is not in the main thread.
If the above is not the case, is it possible that MS IIS is making winsock
calls itself?
What are these folks using for a transport? Could it be a misbehaving TCP?
Maybe a winsock log would help?
Sue
<<< Note 2202.2 by BROKE::BASTINE >>>
-< more >-
Well let me get more specific then...
The customer is running on NT 4.0 and is trying to use MS IIS to create
concurrent access to the web in order to access an Rdb database. He has
this working for a single process, but when he starts using concurrent access
ODBC falls apart with WSAEINPROGRESS errors. When I looked up these errors
in STARS, it indicated that SQL/Services only supported single stream access.
If this isn't true for NT and Win95, anyone have any idea why concurrent access
would fall apart?
Cuatomer is running 2.10.11 of ODBC and 6.0-02 of SQL/Services.
Thanks,
Renee
|