Yeah, I've hoping Wally might chime in, but... This is really a deal breaker right now, and it's giving us a black eye that we can't seem to "fix" whatever this is.
On Thu, Jun 5, 2008 at 5:26 AM, David Wolverton <[EMAIL PROTECTED]> wrote: > 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/ > -- -Kevin http://www.PrecisOnline.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
