I don't think this is relevant, but I'll throw it out there as a longshot....
We had a problem with JDBC where we would get memory leaks if we didn't close our Statements. Closing the connection wasn't enough (in most databases, closing the connection implicitly closes the statements). The Statement held a reference to the Connection which held a reference to all of it's Statements, and the Connection object (which has a HUGE memory footprint!) would hang out forever (thank heavens for profilers for helping us figure this out). Obviously, this is not remotely the same problem, but my point is, assuming the ODBC interface has an analogous Statement object, try making sure you close them if you don't already.... Kevin King wrote: >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: u2-users@listserver.u2ug.org >>>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 >>>>>u2-users@listserver.u2ug.org >>>>>To unsubscribe please visit http://listserver.u2ug.org/ >>>>> >>>>> >>>>------- >>>>u2-users mailing list >>>>u2-users@listserver.u2ug.org >>>>To unsubscribe please visit http://listserver.u2ug.org/ >>>> >>>> >>>> >>> >>>-- >>>-Kevin >>>http://www.PrecisOnline.com >>>------- >>>u2-users mailing list >>>u2-users@listserver.u2ug.org >>>To unsubscribe please visit http://listserver.u2ug.org/ >>> >>> >>------- >>u2-users mailing list >>u2-users@listserver.u2ug.org >>To unsubscribe please visit http://listserver.u2ug.org/ >> >> >> > > > > > -- Geoffrey Mitchell Programmer/Analyst Home Decorator's Collection 314-684-1062 ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
