This is starting to sound like a case that needs to be logged with IBM - We know IBM people watch the list, and the fact no one has chimed in after all this time tells me there's probably more to your issue - it's not going to be a UserList fix, sorry to say! Hopefully the customer has a 'paid in full' maintenance contract - and with this type of error, I'd say you'd be correct as logging it as 'Significant Impact' - holding licenses until people can't work any longer is a BAD thing! I'd love to hear the outcome, as ODBC would be a fast way to get some work done for me - but not if these issues are 'core' and not fixed or fixable via proceess.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King > Sent: Wednesday, June 04, 2008 11:26 PM > To: [email protected] > Subject: Re: [U2] Unidata 7.1 ODBC Threading Problems? > > 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
