Thank you, but there's no file in play; the script is merely calling a
subroutine.  The DSN has the basic connection name, uid, and password.  The
ODBC connection itself is connecting to Unidata via the uci_config
parameters, which doesn't specifically nominate anything about the
connection other than the host name/ip and database type (and a couple
related parameters).

There also doesn't appear to be any locking issues, but then again there's
no locking in my subroutine either.  The problem is that the session just
dies from the client side without logging off the server side and it keeps a
license "hot" until that port is logged off via UniAdmin.  And all that
seems to be causing it is two ODBC calls that overlap.

On Wed, Jun 4, 2008 at 3:33 AM, Brett Callacher <[EMAIL PROTECTED]> wrote:

> 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/
>



-- 
-Kevin
http://www.PrecisOnline.com
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to