RE: [U2] re:form multiple spreadsheets excel file in universe
See also: www.nebula-rnd.com/products/xlite.htm hth Colin Alfke Calgary Canada> > From: louiebergsagel> > The program? What program? We sure could use one.> > -- Louie Bergsagel> North Coast Electric> > On Tue, Jun 3, 2008 at 1:33 PM, Irina Lissok > wrote:> > > Hi everyone,> >> > We have the program which runs and creates separate excel files for> > relational data. _ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata 7.1 ODBC Threading Problems?
This is just a wild thought as I do not know the details of what you are doing. Maybe look at a transaction process around the routine, where you set the transaction level to the lowest. When operating in ODBC you need to deal with RDBMS logic more that U2 for file processing. To get a clean read of a database file, the theory is that you need to lock the file to prevent others updating until you completed a series of reads. Ie if you wanted to total the General Ledger File, it is possible, that while you are reading the GL file, someone else Debit an account you have processed and Credits account that you have not processed, which would make your report not balance, hence why you should lock the file in this type of situation even though you are just reading. By default ODBC might lock that file, it maybe also caused by the ODBC parameters you set up in the calling routine. Words like exclusive, means I have to lock the file. As your routine is not handling an environment like this it maybe causing a fatal for an unexpected expectation. Regards David --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata 7.1 ODBC Threading Problems?
I had a problem like this once when thee software on each end implemented threads differently. One was expecting Apartment threading and the other was expecting something else... I think it was coclass inits. I don't know if that applies here, but it sounds real similar. - Chuck 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. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] re:form multiple spreadsheets excel file in universe
The program? What program? We sure could use one. -- Louie Bergsagel North Coast Electric On Tue, Jun 3, 2008 at 1:33 PM, Irina Lissok <[EMAIL PROTECTED]> wrote: > Hi everyone, > > We have the program which runs and creates separate excel files for > relational data. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata 7.1 ODBC Threading Problems?
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 > >>
RE: [U2] Universe: IF statements in parargraphs don't work anymore
Has anything happened that may have wreaked havoc with your Pick "flavor"? Karen Bessel Software Developer Tyler Technologies, Inc. 6500 International Parkway, Suite 2000 Plano, TX 75093 Phone: 972.713.3770 ext:6227 Fax: 972.713.3777 Email: [EMAIL PROTECTED] Web: http://www.tylertech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Louie Bergsagel Sent: Thursday, June 05, 2008 2:49 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Universe: IF statements in parargraphs don't work anymore I commented out that LOGNAMES line, logged out, and in, and ran LOGIN.TEST again, and it still gives me an "Illegal IF statement." error message. I'm also finding dictionary I-TYPES not working today that worked yesterday: LIST REPORTS START.DATE UD.TODAY WITH START.DATE = UD.TODAY Bad data "=" for conversion "D4/". Unconverted data used for selection. 0 records listed. >.x7 07 LIST DICT REPORTS "START.DATE""UD.TODAY" DICT REPORTS12:45:05pm 05 Jun 2008 Page1 Field. Type & Field Conversion.. Column. Output Depth & Name.. Field. Definition... Code Heading Format Assoc.. Number START.DATE D5 D4/ START.DATE 10R S UD.TODAY I @DATE D4/ UD.TODAY10R S 2 records listed. >>ED REPORTS SELECTed record name = "6765776". 62 lines long. : 5 0005: 14753 : Q --- 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/
Re: [U2] Unidata 7.1 ODBC Threading Problems?
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. __ I'm really not the best U2 support resource to deal with ODBC issues. You really should open a normal support case so the right folks can get engaged at the right level of detail. Regards, Wally Terhune SWG Client Support - Information Management Software U2 Support Architect - IBM U2 Client Support Team 4700 S. Syracuse St., Denver, CO 80237 Tel: (303) 773-7969 Mobile: (303) 807-6222 T/L: 656-7969 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Universe: IF statements in parargraphs don't work anymore
No, that works fine. You only need a label if you want to skip some lines. Turns out somebody had deleted the VOC equal sign record "=". Which brings up a good security question, how do you prevent someone from deleting things? Put shell around ED and DELETE? It would be a bummer to have to make VOC read-only. On Thu, Jun 5, 2008 at 12:53 PM, Ron Hutchings <[EMAIL PROTECTED]> wrote: > On Line 6 don't you need to go to a label to execute a command instead of > trying to directly execute it? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Universe: IF statements in parargraphs don't work anymore
Thanks! Good to know. Nancy Fisher Peninsula Truck Lines, Inc Auburn, Washington 253/929-2040 Visit our Website www.peninsulatruck.com [EMAIL PROTECTED] - Original Message - From: "Louie Bergsagel" <[EMAIL PROTECTED]> To: Sent: Thursday, June 05, 2008 12:56 PM Subject: Re: [U2] Universe: IF statements in parargraphs don't work anymore I found the problem. Somebody had deleted the = VOC record. ED = Unable to open "=", not a file in VOC. I restored it from EQ. -- Louie CT VOC "=""EQ" = 0001 K 0002 4 EQ 0001 K 0002 4 --- 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/
Re: [U2] Universe: IF statements in parargraphs don't work anymore
We had something similar happen once - check if the VOC entery for TERM has been changed. -Dianne At 09:59 AM 6/5/2008, you wrote: IF statements don't work in my paragraphs any more. They worked yesterday. No upgrades or changes that I know of. LOGIN.TEST Your 'VOC' has been modified to use long file names. Illegal IF statement. Illegal IF statement. >CT VOC LOGIN.TEST LOGIN.TEST 0001 PA 0002 PTERM CASE NOINVERT 0003 LONGNAMES ON 0004 TERM ,8 0005 IF @TTY = "phantom" THEN GO END.PARAGRAPH 0006 IF @ACCOUNT = "louie" THEN LOUIEB 0007 END.PARAGRAPH: 0008 * >CT VOC IF IF 0001 K 0002 215 0003 * > UniVerse release.: 10.2.7 UniVerse syntax..: PICK AIX 5.2 Louie Bergsagel North Coast Electric --- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Universe: IF statements in parargraphs don't work anymore
On Line 6 don't you need to go to a label to execute a command instead of trying to directly execute it? > Date: Thu, 5 Jun 2008 09:59:00 -0700 > From: [EMAIL PROTECTED] > To: u2-users@listserver.u2ug.org > Subject: [U2] Universe: IF statements in parargraphs don't work anymore > > IF statements don't work in my paragraphs any more. They worked yesterday. > No upgrades or changes that I know of. > > LOGIN.TEST > Your 'VOC' has been modified to use long file names. > Illegal IF statement. > Illegal IF statement. > > >CT VOC LOGIN.TEST > > LOGIN.TEST > 0001 PA > 0002 PTERM CASE NOINVERT > 0003 LONGNAMES ON > 0004 TERM ,8 > 0005 IF @TTY = "phantom" THEN GO END.PARAGRAPH > 0006 IF @ACCOUNT = "louie" THEN LOUIEB > 0007 END.PARAGRAPH: > 0008 * > > >CT VOC IF > > IF > 0001 K > 0002 215 > 0003 * > > > > UniVerse release.: 10.2.7 > UniVerse syntax..: PICK > AIX 5.2 > > Louie Bergsagel > North Coast Electric > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ _ Its easy to add contacts from Facebook and other social sites through Windows Live Messenger. Learn how. https://www.invite2messenger.net/im/?source=TXT_EML_WLH_LearnHow --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Universe: IF statements in parargraphs don't work anymore
I found the problem. Somebody had deleted the = VOC record. >ED = Unable to open "=", not a file in VOC. I restored it from EQ. -- Louie CT VOC "=""EQ" = 0001 K 0002 4 EQ 0001 K 0002 4 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Universe: IF statements in parargraphs don't work anymore
I commented out that LOGNAMES line, logged out, and in, and ran LOGIN.TEST again, and it still gives me an "Illegal IF statement." error message. I'm also finding dictionary I-TYPES not working today that worked yesterday: LIST REPORTS START.DATE UD.TODAY WITH START.DATE = UD.TODAY Bad data "=" for conversion "D4/". Unconverted data used for selection. 0 records listed. >.x7 07 LIST DICT REPORTS "START.DATE""UD.TODAY" DICT REPORTS12:45:05pm 05 Jun 2008 Page1 Field. Type & Field Conversion.. Column. Output Depth & Name.. Field. Definition... Code Heading Format Assoc.. Number START.DATE D5 D4/ START.DATE 10RS UD.TODAY I @DATE D4/ UD.TODAY10RS 2 records listed. >>ED REPORTS SELECTed record name = "6765776". 62 lines long. : 5 0005: 14753 : Q --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata 7.1 ODBC Threading Problems?
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 > > > connectio
Re: [U2] Universe: IF statements in parargraphs don't work anymore
Louie - I noticed that you have included a LONGNAMES ON statement in this login test. LONGNAMES ON should only be run once in each account, not repeatedly. I don't know if that is your problem, but it might be. Ken At 09:59 AM 6/5/2008, you wrote: IF statements don't work in my paragraphs any more. They worked yesterday. No upgrades or changes that I know of. LOGIN.TEST Your 'VOC' has been modified to use long file names. Illegal IF statement. Illegal IF statement. >CT VOC LOGIN.TEST LOGIN.TEST 0001 PA 0002 PTERM CASE NOINVERT 0003 LONGNAMES ON 0004 TERM ,8 0005 IF @TTY = "phantom" THEN GO END.PARAGRAPH 0006 IF @ACCOUNT = "louie" THEN LOUIEB 0007 END.PARAGRAPH: 0008 * >CT VOC IF IF 0001 K 0002 215 0003 * > UniVerse release.: 10.2.7 UniVerse syntax..: PICK AIX 5.2 Louie Bergsagel North Coast Electric --- 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/
RE: [U2] UniObjects 81009 error
Thanks Symeon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Symeon Breen Sent: June 5, 2008 11:15 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniObjects 81009 error 81009 is rpc failed. This can happen for a number of reasons, it could be network related, it could be the data server timing out your connection. A few points to look at / questions Is this ud or uv ? Does it take a fair amount of time to happen ? - what are your timeout settings for unirpcd etc What else is going on at this time - are there heavy reads and writes ? have you got the network connections set as full duplex - I have had experience of busy systems in half duplex giving this error. Are you using pooling ? - this can happen if the pool is busy and you timeout during the connect. Other things you can try are looking at netstat (if your data server is on linux) and looking at the input and output queues for port 31438 Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of u2ug Sent: 04 June 2008 19:41 To: u2-users@listserver.u2ug.org Subject: [U2] UniObjects 81009 error Occasionally when executing ... UniDataSet DataSet = File.ReadRecords( RecordIds , FieldList ) ... We get this error : IBMU2.UODOTNET.UniFileException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.[IBM U2][UODOTNET - UNIRPC][ErrorCode=81009] The RPC failedTABLENAME at IBMU2.UODOTNET.UniFile.ReadRecords(String[] aRecordIDSet, String[] aFieldNameSet) this happens in a loop using the same File & FieldList - RecordIds varies. Rerunning this same loop will sometimes complete successfully or could generate the above exception at different points - no consistency. Anyone have any insight as to what is causing this error or how to prevent it ? Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.6/1481 - Release Date: 6/3/2008 7:31 PM --- 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/
[U2] Universe: IF statements in parargraphs don't work anymore
IF statements don't work in my paragraphs any more. They worked yesterday. No upgrades or changes that I know of. LOGIN.TEST Your 'VOC' has been modified to use long file names. Illegal IF statement. Illegal IF statement. >CT VOC LOGIN.TEST LOGIN.TEST 0001 PA 0002 PTERM CASE NOINVERT 0003 LONGNAMES ON 0004 TERM ,8 0005 IF @TTY = "phantom" THEN GO END.PARAGRAPH 0006 IF @ACCOUNT = "louie" THEN LOUIEB 0007 END.PARAGRAPH: 0008 * >CT VOC IF IF 0001 K 0002 215 0003 * > UniVerse release.: 10.2.7 UniVerse syntax..: PICK AIX 5.2 Louie Bergsagel North Coast Electric --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniObjects 81009 error
81009 is rpc failed. This can happen for a number of reasons, it could be network related, it could be the data server timing out your connection. A few points to look at / questions Is this ud or uv ? Does it take a fair amount of time to happen ? - what are your timeout settings for unirpcd etc What else is going on at this time - are there heavy reads and writes ? have you got the network connections set as full duplex - I have had experience of busy systems in half duplex giving this error. Are you using pooling ? - this can happen if the pool is busy and you timeout during the connect. Other things you can try are looking at netstat (if your data server is on linux) and looking at the input and output queues for port 31438 Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of u2ug Sent: 04 June 2008 19:41 To: u2-users@listserver.u2ug.org Subject: [U2] UniObjects 81009 error Occasionally when executing ... UniDataSet DataSet = File.ReadRecords( RecordIds , FieldList ) ... We get this error : IBMU2.UODOTNET.UniFileException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.[IBM U2][UODOTNET - UNIRPC][ErrorCode=81009] The RPC failedTABLENAME at IBMU2.UODOTNET.UniFile.ReadRecords(String[] aRecordIDSet, String[] aFieldNameSet) this happens in a loop using the same File & FieldList - RecordIds varies. Rerunning this same loop will sometimes complete successfully or could generate the above exception at different points - no consistency. Anyone have any insight as to what is causing this error or how to prevent it ? Gerry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.6/1481 - Release Date: 6/3/2008 7:31 PM --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata 7.1 ODBC Threading Problems?
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@listserv
