Hi Kevin,

The issue we have had is to with Universe and ODBC and more particularly to do 
with ODBC reads preventing Universe-side writes.  However, you don't seem to be 
getting much response with your issue specifically so maybe this could help.

Make sure that your ODBC DSN entry on the client refers to the account and file 
via its U2 name, i.e. from the perspective of the U2 server.  The problem we 
identified was caused by a reference to a file via its UNC path in the DSN 
settings.  This in turn created an Exclusive Lock on the entire file on the 
server (Windows in this case).

HTH

Brett

"Kevin King" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Is the Unidata 7.1 ODBC driver thread/process safe?
>
> As I've written in previous posts, one of my customers has this Zeacom phone
> system that has the ability to call a (VBScript) script to gather
> information from a back-end database so that it can display that information
> for a customer service rep handing the call.  Conceptually, it's really
> slick.  I had originally written the script using UniObjects, but the
> customer demanded that we use only ODBC to gather the information from
> Unidata, so I rewrote the script using ODBC.  This script opens a connection
> to Unidata, calls a subroutine, gathers the results, and then returns the
> text result to the phone system.  Like I said, it's really slick...
>
> ...except when there are two calls that come in basically at the same time.
> If there's a open ODBC connection to Unidata processing one call and another
> call comes in and opens up another ODBC connection (from the same Windows
> machine from a different process) one or both of the connections craps out,
> leaving a connection open and a license consumed.  We can log these off with
> UniAdmin no problem, but it's a hassle having to watch the user table pretty
> much all day to prevent all of the licenses from being consumed.
>
> The message as logged by the phone system looks like this:
>
> 11:33:46.26 01803d90  QueryThread x755fe0: !! ERROR !! QmScript::Script:
> Error 0x80004005 Line 114 "'D:\Program Files\Zeacom\CTI\Enhanced
> Routing\EnhancedRouting.vbs' line 114: [Microsoft][ODBC Driver Manager]
> Driver's SQLSetConnectAttr failed"
>
> Line 114 of this script is opening the ODBC connection.  Not only did this
> particular connection fail, but the connection that was in progress when
> this one was started died unexpectedly as well, leaving an open connection
> and consumed license.
>
> This script really isn't rocket science, and it's vexing me that we can't
> seem to have multiple open ODBC connections from the same Windows server
> into Unidata.  Is this just a fact of life with Unidata and ODBC, or is
> there a solution?
>
> -Kevin
> http://www.PrecisOnline.com
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to