Jeff,

I would second Rodney Baakkonen's suggestion of writing out your delimited data 
to a Unix directory and ftp the blob to wherever the user would like to find 
it. This vastly expands the possible size limitations you would next hit at the 
Unix level.

Of course if the existing reports consists of a lot of complex dictionaries 
then you would have a programming task you may not want.  Endless alternatives 
spring to mind for that.  Is performance an issue?

Marc Rutherford
Principal Programmer/Analyst
Advanced Bionics LLC
661 362-1754

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jeffrey Butera
Sent: Monday, March 03, 2014 12:34 PM
To: U2 Users List; jscha...@gmail.com
Subject: Re: [U2] Reporting Tools

On 3/3/14, 3:21 PM, Jeff Schasny wrote:
> Jeff,
>
> What I think many of us are suggesting is essentially "if it hurts 
> when you do that, don't do that" i.e. if the query language won't 
> accomplish what you want to do, use something else.

Jeff

Believe me - I hear you (and others).  But my administration isn't listening 
because they all think this is a reasonable request ("excel 
can handle 200+ columns").   So if I can't make this work in Unidata 
I'll have to move to MSSQL which I really, really, really don't want to do.

At this point I'm just trying to understand the limit on the number of fields 
in a LIST statement.  I know in my case that it's not a sentence length issue 
as I might've thought earlier so I'd like to know what is causing this (with 
the understanding that I very well may not be able to solve this).

Jeff



>
> jeffrey Butera wrote:
>> On 3/3/14, 2:58 PM, Brian Leach wrote:
>>> Jeff
>>>
>>> Try mvQuery, that should not have any problems with those volumes.
>>
>> Hi Brian
>>
>> We've isolated the problem to Unidata itself, not the reporting tool.  
>> In short, when we do a LIST with about 150 fields, it throws:
>>
>> "too many items in LIST"
>>
>> As soon as we erase a field (any field), the LIST statement runs 
>> properly.  Unfortunately, I cannot locate any parameter that might 
>> control this.  I thought we were hitting U_SENTLEN - but we're 
>> nowhere near that value.
>>
>>
>>
>


--
Jeffrey Butera, PhD
Associate Director for Application and Web Services Information Technology 
Hampshire College
413-559-5556

_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to