Re: [U2] Unidata Limits

[Daniel McGrath]

Hi Kevin,

As with most software systems, yes there are some very real limitations you 
need to be aware of if you are working with large numbers.

There is a native limit you will hit as UniData converts the number to a double 
and eventually will lose precision. If working with something like a FOR LOOP, 
the engine will use a signed 32-bit number which will wrap around to the 
negative.

For my UniData 7.3 on Windows, I cannot correctly increment beyond 
9007199254740992 natively (doing X+=1).

To get around this there are a series of functions built upon string math you 
will need to use (SADD, SCMP, SMUL, etc). Their limitations are huge (being 
more based on memory bounds than C data-type bounds); I doubt you will 
realistically hit them.

Regards,

Dan McGrath


PROGRAM BOUND.TEST
CRT @(-1)

* Limit is 9007199254740992

X = 900719925474
Y = X

LOOP
   X = 1
   Y = SADD(Y, 1)
   IF Y[LEN(Y)-2,3] = "000" THEN CRT @(-1):X
   IF SCMP(X,Y) # 0 THEN CRT "Limit found: {":X:"} vs {":Y:"}";STOP
REPEAT


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Tuesday, July 10, 2012 1:03 PM
To: U2 Users List
Subject: [U2] Unidata Limits

I was asked a question today that ... well, it stumped me.  Is there a 
practical limit to an incrementing number on Unidata and if so, what is that 
limit?  I seem to recall something way back on Reality that said that numbers 
could count to 1+e38 or something ridiculous like that, but is that still 
applicable?

-K
___
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

Re: [U2] Unidata Limits

[David A. Green]

Since it is stored as a string it can be any length.  If it is used as a Key
or ID of the record you're limited by to 126 characters or whatever your
LIMIT command shows.  And if you need to do math with it you might have to
use string math.

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Tuesday, July 10, 2012 12:03 PM
To: U2 Users List
Subject: [U2] Unidata Limits

I was asked a question today that ... well, it stumped me.  Is there a
practical limit to an incrementing number on Unidata and if so, what is that
limit?  I seem to recall something way back on Reality that said that
numbers could count to 1+e38 or something ridiculous like that, but is that
still applicable?

-K
___
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

[U2] Unidata Limits

[Kevin King]

I was asked a question today that ... well, it stumped me.  Is there a
practical limit to an incrementing number on Unidata and if so, what is
that limit?  I seem to recall something way back on Reality that said that
numbers could count to 1+e38 or something ridiculous like that, but is that
still applicable?

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

Re: [U2] Unidata limits - Where are they documented?

[Kevin King]

Okay, I didn't know about LIMIT.  Too cool.  Thanks!
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Unidata limits - Where are they documented?

[Raymond de Bourbon]

I saw them in the Using UniQuery Manual under the "Basic of Uniquery"

Here are the main limitations:
n Cannot exceed 9247 characters.
n Cannot contain more than 20 sort fields (BY...).
n Cannot contain more than 120 WITH statements.
n Cannot contain more than 60 WHEN statements.
n A WHEN statement cannot process more than 10,240 values in one
attribute.
n Cannot contain more than 54 arithmetic operators (SUM, AVG, PCT,
CALC).
n A BY.EXP statement cannot explode more than 10,240 values in one
attribute.
n Cannot contain more than 15 BREAK.ON/BREAK.SUP clauses.
n Cannot contain more than 999 display attributes.
n A header or footer cannot exceed 2120 characters.
n Cannot contain more than 256 virtual attributes.
n Page width cannot exceed 272 characters.

Regards

Ray


From: owner-u2-us...@listserver.u2ug.org [owner-u2-us...@listserver.u2ug.org] 
On Behalf Of Kevin King [precisonl...@gmail.com]
Sent: 02 April 2009 09:33
To: u2-users@listserver.u2ug.org
Subject: [U2] Unidata limits - Where are they documented?

I have a vague recollection that I've seen something in the Unidata manuals
- years ago - documenting the maximums for a TCL statement, record size,
number of IDs that can be specified in a SELECT statement, that sort of
thing.  I've searched the manual set but I can't seem to locate that
information.  Anyone recall offhand where these are documented?

-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/

RE: [U2] Unidata limits - Where are they documented?

[Marc Harbeson]

>From TCL: LIMIT?

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, April 02, 2009 10:34 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Unidata limits - Where are they documented?

I have a vague recollection that I've seen something in the Unidata
manuals
- years ago - documenting the maximums for a TCL statement, record size,
number of IDs that can be specified in a SELECT statement, that sort of
thing.  I've searched the manual set but I can't seem to locate that
information.  Anyone recall offhand where these are documented?

-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/

[U2] Unidata limits - Where are they documented?

[Kevin King]

I have a vague recollection that I've seen something in the Unidata manuals
- years ago - documenting the maximums for a TCL statement, record size,
number of IDs that can be specified in a SELECT statement, that sort of
thing.  I've searched the manual set but I can't seem to locate that
information.  Anyone recall offhand where these are documented?

-Kevin
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Anthony W. Youngman]

In message <4983be3c.4070...@advantos.net>, Bill Haskett 
 writes

  Ken:
  I think so.  I'm looking at this as the best (or easiest) alternative.
  Thanks very much for the thought.
  Bill


I've rethought my idea a bit. What I don't quite get is how you build up 
that massive list of clients in the first place. Am I correct in 
thinking you own the customers, the customers own the clients? Okay.


How does the database know which clients are owned by which customers? 
Sensible design says the CLIENT file will have a field called 
CUSTOMER.OWNER (or similar). Certainly there won't be a list of clients 
in the CUSTOMER file - that could be a massive mv list and is poor poor 
poor design ...


So you should be able to do a

EVAL "LOCATE( CUSTOMER.ID , TRANS( CLIENT, CLIENT.ID, "CUSTOMER.OWNER", 
"X"), 1, 1, 1)"


in your query. Note I'm not sure of the locate syntax, I'm looking for a 
sub-value (assuming CUSTOMER.OWNER is multi-valued and TRANS does a 
LOWER). If this returns true, your customer can see this client.


There's your select, and it'll probably run faster, too :-)

Cheers,
Wol
--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Bill Haskett]

   Ken:
   I think so.  I'm looking at this as the best (or easiest) alternative.
   Thanks very much for the thought.
   Bill
   __

   From: Ken Wallis 
   Sent: 1/30/2009 6:43 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

So can't you substitute your bit of code that puts 'WITH CLIENTNO =
':MYBIGCOMMONLISTOFLITERALS into all your SELECTs and SORTs with
something that puts 'WITH EVAL
"SUBR(MYROUTINETHATLOCATESINCOMMONLITERALS,CLIENTNO)"' in the same place and
get the same results?

HTH,

Ken

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Saturday, 31 January 2009 8:23 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   Micki:
   Thanks for the thoughts.  We do have a single subroutine that parses the
   list of clients/stores/departments authorized access by each user.  This
   list, for each user, is loaded into named common.  Users print/process
some,
   most,  or all information for these entities (from whatever file is of
   interest at the moment) all of the time.  A single input subroutine is
used
   for each report/process that asks the user what entity(s) they want to
use.
   When the user is done selecting, this list is also held in common.  All
   subroutines simply substitute this list into the report/process.
---
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 LIMITs

[Ken Wallis]

So can't you substitute your bit of code that puts 'WITH CLIENTNO =
':MYBIGCOMMONLISTOFLITERALS into all your SELECTs and SORTs with
something that puts 'WITH EVAL
"SUBR(MYROUTINETHATLOCATESINCOMMONLITERALS,CLIENTNO)"' in the same place and
get the same results?

HTH,

Ken

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Saturday, 31 January 2009 8:23 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   Micki:
   Thanks for the thoughts.  We do have a single subroutine that parses the
   list of clients/stores/departments authorized access by each user.  This
   list, for each user, is loaded into named common.  Users print/process
some,
   most,  or all information for these entities (from whatever file is of
   interest at the moment) all of the time.  A single input subroutine is
used
   for each report/process that asks the user what entity(s) they want to
use.
   When the user is done selecting, this list is also held in common.  All
   subroutines simply substitute this list into the report/process.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Scott Ballinger]

Just goes to show that a problem like this will generate the same solution
many times over.My version of Chuck's XSELECT is called BSELECT.

e.g.
GET-LIST MYLIST (list of customer numbers)
BSELECT INVOICES CUST.NO(cust.no is an indexed field in INVOICES file)

Once you get used to it, it is indispensable. (I have a D3 version too...)

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

 BSELECT
* select records with indexed field matching a select list
* 09-12-06 asb: UV version
* usage: BSELECT target-file indexed-field

**$OPTIONS DEFAULT

TOT = @SELECTED
IF TOT ELSE STOPM "this process requires an active select list"

PROMPT ""

BUF = TRIM(@SENTENCE)
TARGETFILE = ""
FIELDNAME = ""

IF FIELD(BUF," ",1) EQ "RUN" THEN
  BUF = OCONV(BUF,"G2 99")
END
TARGETFILE = FIELD(BUF," ",2)
FIELDNAME  = FIELD(BUF," ",3)

IF TARGETFILE EQ "" THEN
  PRINT "Target file to select against: ":
  INPUT TARGETFILE
  CALL INPUT.TEST(TARGETFILE)  ;* test for standard quit type responses
  IF TARGETFILE EQ "" OR TARGETFILE EQ "QUIT" THEN STOP
END
OPEN TARGETFILE TO FV ELSE STOP 201,TARGETFILE

IF FIELDNAME EQ "" THEN
  PRINT "Indexed field on ":TARGETFILE:": ":
  INPUT FIELDNAME
  CALL INPUT.TEST(FIELDNAME)
  IF FIELDNAME EQ "" OR FIELDNAME EQ "QUIT" THEN STOP
END

C= 0  ;* original list ids processed
C1   = 0  ;* original list ids found in target file via fieldname btree
C2   = 0  ;* new ids to target file returned
T= TIME()
D= DATE()
CLR  = @(0):@(-4)
LIST = ""

10 *

READNEXT ID ELSE GO 999

BSCAN CID,REC FROM FV,ID USING FIELDNAME THEN

  IF CID EQ ID THEN
LIST<-1> = REC
C1 += 1
C2 += DCOUNT(REC,@AM)
  END

END

C += 1
IF MOD(C,1000) EQ 0 THEN
  CALL COUNTER.SUB(C,T,D,TOT,TXT)  ;* calc percent done & estimated time
until finished
  PRINT CLR:C:" ":C1:" ":C2:TXT:
END

GO 10

999 *

CALL FINAL.COUNT(C,T,D)  ;* nnn records processed in yyy seconds = zzz.z per
second.
PRINT C1:" ids found in '":FIELDNAME:"' field on '":TARGETFILE:"' file."
PRINT C2:" '":TARGETFILE:"' records selected."

IF C2 EQ 0 THEN
  STOP 401
END ELSE
  OPEN "&SAVEDLISTS&" TO SL ELSE STOP 201,"&SAVEDLISTS&"
  LID = "BSELECT":SYSTEM(22)
  WRITE LIST ON SL,LID
  CHAIN "GET-LIST ":LID
END


On Fri, Jan 30, 2009 at 2:24 PM, Charles Stevenson  wrote:

> I'm entering the fray late here, but I think I have a good, fast,
> general solution, provided you're willing to index a field.   I should
> probably post it in U2UG's wiki the source code to the XSELECT utility
> below.
>
> Using your example, SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4". :
> 1. Maintain an index on COSTOMERS CLIENTNO.
> 2. Create a saved or active select list of the 300 client numbers.
>Others have suggested how via QSELECT, FORM.LIST etc.
> 3. Use XSELECT utility verb that uses basic SELECTINDEX under the covers to
> build a select list of all CUSTOMERS keys that are indexed by those 300
> client numbers.
>
> >GET.LIST A.BUNCH.OF.CLIENTS
> 300 records selected.
> >>XSELECT CUSTOMERS CLIENTNO
> 12,345 records selected  <--- 12,345 CUSTOMER IDs
> >>LIST CUSTOMERS REQUIRE.SELECT ... ( or however you generate the
> report.)
>
>
> The nut of  XSELECT pretty much does this:
>   outlist = ''
>   loop while readnext idxval
>  selectindex idx, idxval from fvar to 0
>  readlist temp from 0 then outlist<-1> = temp
>   repeat
> but there's logic for oconv, duplicates, saving/getting lists, existing
> with
> active select list, error handling, etc. that you'll need if you roll your
> own.
> Chuck Stevenson
>
>
>
> On Thu, Jan 29, 2009 at 11:43 AM, Bill Haskett  wrote:
>
> >   We have a report writer that allows users to select the client they
> want
> > to
> >   print any report for.  This subroutine builds a list of clients
> available
> > to
> >   any particular user and uses this list to either compare against the
> > clients
> >   entered or of all clients are selected then the entire list is used.
> >  When
> >   this list is placed in an ECL query and executed, e.g
> >   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
> >   ...all has been fine for years.  We picked up a new customer who has
> over
> >   300 clients.  When a user tries to run a report for all clients
> > accessible
> >   by them the query aborts with...
> >   WITH condition stack overflow
> ---
> 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 LIMITs

[Charles Stevenson]

I'm entering the fray late here, but I think I have a good, fast,
general solution, provided you're willing to index a field.   I should
probably post it in U2UG's wiki the source code to the XSELECT utility
below.

Using your example, SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4". :
1. Maintain an index on COSTOMERS CLIENTNO.
2. Create a saved or active select list of the 300 client numbers.
Others have suggested how via QSELECT, FORM.LIST etc.
3. Use XSELECT utility verb that uses basic SELECTINDEX under the covers to
build a select list of all CUSTOMERS keys that are indexed by those 300
client numbers.

>GET.LIST A.BUNCH.OF.CLIENTS
300 records selected.
>>XSELECT CUSTOMERS CLIENTNO
12,345 records selected  <--- 12,345 CUSTOMER IDs
>>LIST CUSTOMERS REQUIRE.SELECT ... ( or however you generate the
report.)


The nut of  XSELECT pretty much does this:
   outlist = ''
   loop while readnext idxval
  selectindex idx, idxval from fvar to 0
  readlist temp from 0 then outlist<-1> = temp
   repeat
but there's logic for oconv, duplicates, saving/getting lists, existing with
active select list, error handling, etc. that you'll need if you roll your
own.
Chuck Stevenson



On Thu, Jan 29, 2009 at 11:43 AM, Bill Haskett  wrote:

>   We have a report writer that allows users to select the client they want
> to
>   print any report for.  This subroutine builds a list of clients available
> to
>   any particular user and uses this list to either compare against the
> clients
>   entered or of all clients are selected then the entire list is used.
>  When
>   this list is placed in an ECL query and executed, e.g
>   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
>   ...all has been fine for years.  We picked up a new customer who has over
>   300 clients.  When a user tries to run a report for all clients
> accessible
>   by them the query aborts with...
>   WITH condition stack overflow
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Bill Haskett]

   Micki:
   Thanks for the thoughts.  We do have a single subroutine that parses the
   list of clients/stores/departments authorized access by each user.  This
   list, for each user, is loaded into named common.  Users print/process some,
   most,  or all information for these entities (from whatever file is of
   interest at the moment) all of the time.  A single input subroutine is used
   for each report/process that asks the user what entity(s) they want to use.
   When the user is done selecting, this list is also held in common.  All
   subroutines simply substitute this list into the report/process.
   This method has worked fine for practical reasons.  Now, with new markets
   opening up this has become one of the few "scaling" issues we've run into.
   I'd use a translate if users only wanted to process data for one or all of
   the entities.  This rarely happens on a practical basis; there are many
   times they need to select from a large list of clients/stores/departments,
   for management purposes, auditing purposes, gov't purposes, etc.
   Please  forgive me for mentioning the name"D3"; I sometimes forget the
   ability this name has in raising the blood pressure of many people.  I only
   used the name to point out why the problem hasn't happened previously.
   Thanks again for the thoughts.
   Bill
   __

   From: Mecki Foerthmann 
   Sent: 1/30/2009 12:27 AM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

 Do the users have to type in all 300 customer numbers every time they want
 to run a report?
 Certainly not?
 So there must be a file containing these numbers with some sort of ID.
 In that case there should be then a routine (be it a Basic program, a Proc
 or Paragraph) that merges that data into the TCL-statement and is used in
 all these reports.
 I think Kevin King's approach using dictionaries with a SUBR(,, is the
 most reasonable and least work intensive solution.
 Or is that actually repeated code in every report in the system?
 In which case I would say, 'tough luck'.
 Nothing to do with conversion hassles, since I don't believe that D3 can
 handle an unlimited number of arguments in a TCL-statement either.
 You ran into this on UD with 300 clients, on D3 it might happen at 350 or
 500, and what then?
 Is D3 then rubbish too?
 This only proves that bad coding practices and 'lazy' or 'dirty' solutions
 always come back to haunt you.
 Mecki
 Bill Haskett wrote:

This is a good thought but we've got multiple files with tons of
 records in
them.  Our users can be restricted from accessing records throughout
 the
application that are associated with particular clients/departments.
 Thus,
when they want to select A/P invoices to pay, the user would generate:
:SSELECT  APINVOICES  WITH  AUTHORIZED  AND  WITH  CLIENTNO  =  "A long
 list
of clients"
This may be a short list but for really large customers of ours, this
 list
may exceed 200-300 clients/departments for a particular user.  In this
example,  the  client  number is in field# 2.  What brought this to my
attention is we upgraded a large customer of ours from D3 to UniData
 and
they have 300 clients (several users have access to 275 of them).  I've
 only
used QSELECT to select the attributes of a record(s) and that's not
 what we
want here; we want all A/P invoices for the selected clients so they
 can be
paid.  So I'm not selecting multiple items specifying explicit item its
 but
selecting thousands of records where the client number is defined as
 the
ones the user is authorized to access.
 What's really difficult is many of our reports are "SORT"s, not
 "SELECT"s.
This gives me no way to split apart a single report.  I'd have to
 process
the report in multiple parts, taking into account the dependency the
 reports
have with the spooler and the interaction with the user.
Whew!  It's tough to grow and run into 25 year old limitations applied
 to
modern hardware.  :-(
Thanks again.
Bill
______________
From: Ken Wallis 
Sent: 1/29/2009 9:04 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs
 The problem here isn't that you can only have a certain number of items
 active in a select list, but that specifying them as explicit item ids on
 the command line is ugly, bad and only supported up to a certain point.
 Isn't this a job fo

RE: [U2] UniData LIMITs

[Anthony Youngman]

My idea would be to:

Create a field in the CLIENT file that contains a list of all users that can 
see that client.

Create an i-descriptor in the file that you're reporting on that pulls that 
field across.

Use a WHEN or WITH (can never remember which) to only pick records where that 
user's id appears in that field. (Or create a subroutine which returns an 
"allow" or "deny" field and only select "allow"ed records.)

Cheers,
Wol

-Original Message-
From: owner-u2-us...@listserver.u2ug.org 
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of David A. Green
Sent: 30 January 2009 12:49
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData LIMITs

Bill,

I would create a CLIENT Type field that you can lump the CLIENTS together
and use the Type field for your selections.

Thanks,
David A. Green
www.dagconsulting.com
(480) 813-1725


-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 12:44 PM
To: U2 Mail List
Subject: [U2] UniData LIMITs

   We have a report writer that allows users to select the client they want
to
   print any report for.  This subroutine builds a list of clients available
to
   any particular user and uses this list to either compare against the
clients
   entered or of all clients are selected then the entire list is used.
When
   this list is placed in an ECL query and executed, e.g
   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
   ...all has been fine for years.  We picked up a new customer who has over
   300 clients.  When a user tries to run a report for all clients
accessible
   by them the query aborts with...
   WITH condition stack overflow
   A quick look at "LIMIT" shows:
   :LIMIT
   U_MAXFNAME:  File name limit =   198.
   U_NAMESZ:Record id(key) size =   126.
   U_SELEMAX:   Number of select list = 10.
   U_MAXDATA:   Number of DATA statement =  500.
   U_HEADSZ:HEADER/FOOTER length =  2120.
   U_MAXHASHTYPES: Number of hash functions =   3.
   U_MAXSORT:   Number of sort fields(BY...) in LIST =  20.
   U_MAXWITH:   WITH stack size =   256.
   U_MAXWHEN:   WHEN stack size =   60.
   U_MAXCAL:Number of SUM+AVG+PCT+CAL in LIST = 54.
   U_MAXBREAK:  Number of BREAK.ON+BREAK.SUP in LIST =  15.
   U_MAXLIST:   Number of attribute names in LIST = 999.
   U_LINESZ:Page width in printing =272.
   U_PARASIZE:  Paragraph name and its parameter size = 256.
   U_LPCMD: System spooler name =   NT Spooler.
   U_MAXPROMPT: Number of prompts allowed in paragraph =  60.
   U_FSIZE: Dictionary field name size =31.
   U_MAXVALUE:  Number of values WHEN can handle =  10240.
   U_MAXBYEXPVAL:  Number of values BY.EXP can handle =  10240.
   U_SENTLEN:   Maximum sentence length =   9247.
   U_PROCBUFSZ:  Proc buffer size = 8191.
   U_NIDES: Maximum number of virtual fields in query=  256
   ...which indicates there's a limit of data allowed in the "WITH"
clause(s)
   of  256.   The UniData documentation says these parameters are __NOT__
   configurable.   How  in  the  world  are  other people overcoming this
   limitation?  Doesn't anyone want data for more than 256 somethings?  Is
it
   possible  for  me to overcome this limitation without going into 1,000
   programs to split large numbers of ECL queries?  Or am I forced to count
the
   "somethings" available to submit to any query and abort if its more than
   250?  Am I forced to split up A/P check runs (and many other processes)
into
   two or more runs to accommodate this limitation?
   Any experience, or thoughts, on this will be appreciated.
   Bill
---
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-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UniData LIMITs

[David A. Green]

Bill,

I would create a CLIENT Type field that you can lump the CLIENTS together
and use the Type field for your selections.

Thanks,
David A. Green
www.dagconsulting.com
(480) 813-1725


-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 12:44 PM
To: U2 Mail List
Subject: [U2] UniData LIMITs

   We have a report writer that allows users to select the client they want
to
   print any report for.  This subroutine builds a list of clients available
to
   any particular user and uses this list to either compare against the
clients
   entered or of all clients are selected then the entire list is used.
When
   this list is placed in an ECL query and executed, e.g
   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
   ...all has been fine for years.  We picked up a new customer who has over
   300 clients.  When a user tries to run a report for all clients
accessible
   by them the query aborts with...
   WITH condition stack overflow
   A quick look at "LIMIT" shows:
   :LIMIT
   U_MAXFNAME:  File name limit =   198.
   U_NAMESZ:Record id(key) size =   126.
   U_SELEMAX:   Number of select list = 10.
   U_MAXDATA:   Number of DATA statement =  500.
   U_HEADSZ:HEADER/FOOTER length =  2120.
   U_MAXHASHTYPES: Number of hash functions =   3.
   U_MAXSORT:   Number of sort fields(BY...) in LIST =  20.
   U_MAXWITH:   WITH stack size =   256.
   U_MAXWHEN:   WHEN stack size =   60.
   U_MAXCAL:Number of SUM+AVG+PCT+CAL in LIST = 54.
   U_MAXBREAK:  Number of BREAK.ON+BREAK.SUP in LIST =  15.
   U_MAXLIST:   Number of attribute names in LIST = 999.
   U_LINESZ:Page width in printing =272.
   U_PARASIZE:  Paragraph name and its parameter size = 256.
   U_LPCMD: System spooler name =   NT Spooler.
   U_MAXPROMPT: Number of prompts allowed in paragraph =  60.
   U_FSIZE: Dictionary field name size =31.
   U_MAXVALUE:  Number of values WHEN can handle =  10240.
   U_MAXBYEXPVAL:  Number of values BY.EXP can handle =  10240.
   U_SENTLEN:   Maximum sentence length =   9247.
   U_PROCBUFSZ:  Proc buffer size = 8191.
   U_NIDES: Maximum number of virtual fields in query=  256
   ...which indicates there's a limit of data allowed in the "WITH"
clause(s)
   of  256.   The UniData documentation says these parameters are __NOT__
   configurable.   How  in  the  world  are  other people overcoming this
   limitation?  Doesn't anyone want data for more than 256 somethings?  Is
it
   possible  for  me to overcome this limitation without going into 1,000
   programs to split large numbers of ECL queries?  Or am I forced to count
the
   "somethings" available to submit to any query and abort if its more than
   250?  Am I forced to split up A/P check runs (and many other processes)
into
   two or more runs to accommodate this limitation?
   Any experience, or thoughts, on this will be appreciated.
   Bill
---
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 LIMITs

[djordan]

Hi Bill

I can't see users selecting 300 users, there must be another criteria that
they choose to get those clients, can't that be used instead.

Otherwise:

I would set up another file "SELECTEDCLIENTS" with key @UserNo*Clientno with
f1 = 1 which holds the clientnos the user wants.  The core subroutine builds
that file.

Then instead of using clientno = .  in your selects use a
TRANS(SELECTEDCLIENTS,@userno:"*":f2,1,'x') = 1

If it is not on SELECTEDCLIENTS it will return "" and only those items on
SELECTEDCLIENTS will be selected.

It is just an idea, and processing may be faster.

Regards

David Jordan
Managing Consultant

Dacono Holdings Pty Ltd
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Mecki Foerthmann]

Do the users have to type in all 300 customer numbers every time they 
want to run a report?

Certainly not?
So there must be a file containing these numbers with some sort of ID.
In that case there should be then a routine (be it a Basic program, a 
Proc or Paragraph) that merges that data into the TCL-statement and is 
used in all these reports.
I think Kevin King's approach using dictionaries with a SUBR(,, is the 
most reasonable and least work intensive solution.

Or is that actually repeated code in every report in the system?
In which case I would say, 'tough luck'.
Nothing to do with conversion hassles, since I don't believe that D3 can 
handle an unlimited number of arguments in a TCL-statement either.
You ran into this on UD with 300 clients, on D3 it might happen at 350 
or 500, and what then?

Is D3 then rubbish too?
This only proves that bad coding practices and 'lazy' or 'dirty' 
solutions always come back to haunt you.


Mecki

Bill Haskett wrote:

   This is a good thought but we've got multiple files with tons of records in
   them.  Our users can be restricted from accessing records throughout the
   application that are associated with particular clients/departments.  Thus,
   when they want to select A/P invoices to pay, the user would generate:
   :SSELECT  APINVOICES  WITH  AUTHORIZED  AND  WITH  CLIENTNO  =  "A long list
   of clients"
   This may be a short list but for really large customers of ours, this list
   may exceed 200-300 clients/departments for a particular user.  In this
   example,  the  client  number is in field# 2.  What brought this to my
   attention is we upgraded a large customer of ours from D3 to UniData and
   they have 300 clients (several users have access to 275 of them).  I've only
   used QSELECT to select the attributes of a record(s) and that's not what we
   want here; we want all A/P invoices for the selected clients so they can be
   paid.  So I'm not selecting multiple items specifying explicit item its but
   selecting thousands of records where the client number is defined as the
   ones the user is authorized to access.
   What's really difficult is many of our reports are "SORT"s, not "SELECT"s.
   This gives me no way to split apart a single report.  I'd have to process
   the report in multiple parts, taking into account the dependency the reports
   have with the spooler and the interaction with the user.
   Whew!  It's tough to grow and run into 25 year old limitations applied to
   modern hardware.  :-(
   Thanks again.
   Bill
   __

   From: Ken Wallis 
   Sent: 1/29/2009 9:04 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

The problem here isn't that you can only have a certain number of items
active in a select list, but that specifying them as explicit item ids on
the command line is ugly, bad and only supported up to a certain point.

Isn't this a job for QSELECT?

PS.  As much as I think UniData is a great toolset to work with, anyone who
told you that conversion was a save and restore needs shooting.

Cheers,

Ken

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Marc Harbeson
Sent: Friday, 30 January 2009 12:24 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData LIMITs

What about something along the lines of splitting the client ID's into
two (or more) lists, selecting, and then MERGE.LIST them together then
list?

Kind of difficult to guess around it without seeing the whole picture.

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   That's correct.
   Bill

__________

   From: Kevin King 
   Sent: 1/29/2009 2:37 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a
company
number or such that you could use in the selection?
---
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 LIMITs

[Bill Haskett]

   This is a good thought but we've got multiple files with tons of records in
   them.  Our users can be restricted from accessing records throughout the
   application that are associated with particular clients/departments.  Thus,
   when they want to select A/P invoices to pay, the user would generate:
   :SSELECT  APINVOICES  WITH  AUTHORIZED  AND  WITH  CLIENTNO  =  "A long list
   of clients"
   This may be a short list but for really large customers of ours, this list
   may exceed 200-300 clients/departments for a particular user.  In this
   example,  the  client  number is in field# 2.  What brought this to my
   attention is we upgraded a large customer of ours from D3 to UniData and
   they have 300 clients (several users have access to 275 of them).  I've only
   used QSELECT to select the attributes of a record(s) and that's not what we
   want here; we want all A/P invoices for the selected clients so they can be
   paid.  So I'm not selecting multiple items specifying explicit item its but
   selecting thousands of records where the client number is defined as the
   ones the user is authorized to access.
   What's really difficult is many of our reports are "SORT"s, not "SELECT"s.
   This gives me no way to split apart a single report.  I'd have to process
   the report in multiple parts, taking into account the dependency the reports
   have with the spooler and the interaction with the user.
   Whew!  It's tough to grow and run into 25 year old limitations applied to
   modern hardware.  :-(
   Thanks again.
   Bill
   __

   From: Ken Wallis 
   Sent: 1/29/2009 9:04 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

The problem here isn't that you can only have a certain number of items
active in a select list, but that specifying them as explicit item ids on
the command line is ugly, bad and only supported up to a certain point.

Isn't this a job for QSELECT?

PS.  As much as I think UniData is a great toolset to work with, anyone who
told you that conversion was a save and restore needs shooting.

Cheers,

Ken

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Marc Harbeson
Sent: Friday, 30 January 2009 12:24 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData LIMITs

What about something along the lines of splitting the client ID's into
two (or more) lists, selecting, and then MERGE.LIST them together then
list?

Kind of difficult to guess around it without seeing the whole picture.

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   That's correct.
   Bill

__

   From: Kevin King 
   Sent: 1/29/2009 2:37 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a
company
number or such that you could use in the selection?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UniData LIMITs

[Ken Wallis]

The problem here isn't that you can only have a certain number of items
active in a select list, but that specifying them as explicit item ids on
the command line is ugly, bad and only supported up to a certain point.

Isn't this a job for QSELECT?

PS.  As much as I think UniData is a great toolset to work with, anyone who
told you that conversion was a save and restore needs shooting.

Cheers,

Ken

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Marc Harbeson
Sent: Friday, 30 January 2009 12:24 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniData LIMITs

What about something along the lines of splitting the client ID's into
two (or more) lists, selecting, and then MERGE.LIST them together then
list?

Kind of difficult to guess around it without seeing the whole picture.

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   That's correct.
   Bill
 
__

   From: Kevin King 
   Sent: 1/29/2009 2:37 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a
company
number or such that you could use in the selection?
---
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-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 LIMITs

[Bill Haskett]

   Charlie:
   Thanks.  The client number is at the core of our ERP package.  A quick look
   shows  over 150 reports using a core subroutine to enter clients while
   another 100 use the client number field.
   Does this constant re-engineering crap ever end?  [sigh]Never believe
   someone who says a conversion is nothing more than a backup and a restore.
   :-)
   Bill
   __

   From: Charlie Rubeor 
   Sent: 1/29/2009 6:44 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

When I ran into this issue, that's the solution that I used.  It's not
pretty, but I would be happy to share the code.

I was really hoping that someone else had a better solution.

- Original Message -
From: "Marc Harbeson" 
To: 
Sent: Thursday, January 29, 2009 8:24 PM
Subject: RE: [U2] UniData LIMITs

What about something along the lines of splitting the client ID's into
two (or more) lists, selecting, and then MERGE.LIST them together then
list?

Kind of difficult to guess around it without seeing the whole picture.

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

  That's correct.
  Bill

__

  From: Kevin King 
  Sent: 1/29/2009 2:37 PM
  To: u2-users@listserver.u2ug.org
  Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a
company
number or such that you could use in the selection?
---
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-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[demime 1.01d removed an attachment of type application/pgp-signature which had
 a name of PGP.sig]
---
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 LIMITs

[Charlie Rubeor]

When I ran into this issue, that's the solution that I used.  It's not 
pretty, but I would be happy to share the code.

I was really hoping that someone else had a better solution.

- Original Message - 
From: "Marc Harbeson" 
To: 
Sent: Thursday, January 29, 2009 8:24 PM
Subject: RE: [U2] UniData LIMITs


> What about something along the lines of splitting the client ID's into
> two (or more) lists, selecting, and then MERGE.LIST them together then
> list?
>
> Kind of difficult to guess around it without seeing the whole picture.
>
> -Original Message-
> From: owner-u2-us...@listserver.u2ug.org
> [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
> Sent: Thursday, January 29, 2009 7:12 PM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] UniData LIMITs
>
>   That's correct.
>   Bill
>
> __
>
>   From: Kevin King 
>   Sent: 1/29/2009 2:37 PM
>   To: u2-users@listserver.u2ug.org
>   Subject: Re: [U2] UniData LIMITs
>
> And the client records don't share any specific attribute, like a
> company
> number or such that you could use in the selection?
> ---
> 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-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of PGP.sig]
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UniData LIMITs

[Marc Harbeson]

What about something along the lines of splitting the client ID's into
two (or more) lists, selecting, and then MERGE.LIST them together then
list?

Kind of difficult to guess around it without seeing the whole picture.

-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniData LIMITs

   That's correct.
   Bill
 
__

   From: Kevin King 
   Sent: 1/29/2009 2:37 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a
company
number or such that you could use in the selection?
---
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-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Bill Haskett]

   That's correct.
   Bill
   __

   From: Kevin King 
   Sent: 1/29/2009 2:37 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

And the client records don't share any specific attribute, like a company
number or such that you could use in the selection?
---
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 LIMITs

[Kevin King]

And the client records don't share any specific attribute, like a company
number or such that you could use in the selection?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData LIMITs

[Bill Haskett]

   Marc:
   I don't think so because the reports may be:
   SELECT  CUSTOMERS  WITH  CLIENTNO  =  "1""2""5""7""11"...
   -or-
   SELECT  APINVOICES  WITH  CLIENTNO  =  "1""3""4""6""8""9"...
   -or-
   SELECT  EMPLOYEES  WITH  CLIENTNO  =  "1""2""3""4""5"...
   ...etc, etc, etc.  These aren't just individual records but large numbers of
   records, in many files, for a specific department style client; where the
   client number is often one of the fields in the record.  Every report in our
   system  uses  a client number search, since all accounting records are
   client-centric.
   Bill
   ______________

   From: Marc Harbeson 
   Sent: 1/29/2009 1:54 PM
   To: u2-users@listserver.u2ug.org
   Subject: Re: [U2] UniData LIMITs

Can't you just FORMLIST them, then list?

Aka:

CLIENTIDS = "1":@AM:"2"
FORMLIST CLIENTIDS TO 0


-Original Message-----
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 2:44 PM
To: U2 Mail List
Subject: [U2] UniData LIMITs

   We have a report writer that allows users to select the client they
want to
   print any report for.  This subroutine builds a list of clients
available to
   any particular user and uses this list to either compare against the
clients
   entered or of all clients are selected then the entire list is used.
When
   this list is placed in an ECL query and executed, e.g
   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
   ...all has been fine for years.  We picked up a new customer who has
over
   300 clients.  When a user tries to run a report for all clients
accessible
   by them the query aborts with...
   WITH condition stack overflow
   A quick look at "LIMIT" shows:
   :LIMIT
   U_MAXFNAME:  File name limit =   198.
   U_NAMESZ:Record id(key) size =   126.
   U_SELEMAX:   Number of select list = 10.
   U_MAXDATA:   Number of DATA statement =  500.
   U_HEADSZ:HEADER/FOOTER length =  2120.
   U_MAXHASHTYPES: Number of hash functions =   3.
   U_MAXSORT:   Number of sort fields(BY...) in LIST =  20.
   U_MAXWITH:   WITH stack size =   256.
   U_MAXWHEN:   WHEN stack size =   60.
   U_MAXCAL:Number of SUM+AVG+PCT+CAL in LIST = 54.
   U_MAXBREAK:  Number of BREAK.ON+BREAK.SUP in LIST =  15.
   U_MAXLIST:   Number of attribute names in LIST = 999.
   U_LINESZ:Page width in printing =272.
   U_PARASIZE:  Paragraph name and its parameter size = 256.
   U_LPCMD: System spooler name =   NT Spooler.
   U_MAXPROMPT: Number of prompts allowed in paragraph =  60.
   U_FSIZE: Dictionary field name size =31.
   U_MAXVALUE:  Number of values WHEN can handle =  10240.
   U_MAXBYEXPVAL:  Number of values BY.EXP can handle =  10240.
   U_SENTLEN:   Maximum sentence length =   9247.
   U_PROCBUFSZ:  Proc buffer size = 8191.
   U_NIDES: Maximum number of virtual fields in query=  256
   ...which indicates there's a limit of data allowed in the "WITH"
clause(s)
   of  256.   The UniData documentation says these parameters are
__NOT__
   configurable.   How  in  the  world  are  other people overcoming
this
   limitation?  Doesn't anyone want data for more than 256 somethings?
Is it
   possible  for  me to overcome this limitation without going into
1,000
   programs to split large numbers of ECL queries?  Or am I forced to
count the
   "somethings" available to submit to any query and abort if its more
than
   250?  Am I forced to split up A/P check runs (and many other
processes) into
   two or more runs to accommodate this limitation?
   Any experience, or thoughts, on this will be appreciated.
   Bill
---
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-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] UniData LIMITs

[Marc Harbeson]

Can't you just FORMLIST them, then list?

Aka:

CLIENTIDS = "1":@AM:"2"
FORMLIST CLIENTIDS TO 0




-Original Message-
From: owner-u2-us...@listserver.u2ug.org
[mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 2:44 PM
To: U2 Mail List
Subject: [U2] UniData LIMITs

   We have a report writer that allows users to select the client they
want to
   print any report for.  This subroutine builds a list of clients
available to
   any particular user and uses this list to either compare against the
clients
   entered or of all clients are selected then the entire list is used.
When
   this list is placed in an ECL query and executed, e.g
   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
   ...all has been fine for years.  We picked up a new customer who has
over
   300 clients.  When a user tries to run a report for all clients
accessible
   by them the query aborts with...
   WITH condition stack overflow
   A quick look at "LIMIT" shows:
   :LIMIT
   U_MAXFNAME:  File name limit =   198.
   U_NAMESZ:Record id(key) size =   126.
   U_SELEMAX:   Number of select list = 10.
   U_MAXDATA:   Number of DATA statement =  500.
   U_HEADSZ:HEADER/FOOTER length =  2120.
   U_MAXHASHTYPES: Number of hash functions =   3.
   U_MAXSORT:   Number of sort fields(BY...) in LIST =  20.
   U_MAXWITH:   WITH stack size =   256.
   U_MAXWHEN:   WHEN stack size =   60.
   U_MAXCAL:Number of SUM+AVG+PCT+CAL in LIST = 54.
   U_MAXBREAK:  Number of BREAK.ON+BREAK.SUP in LIST =  15.
   U_MAXLIST:   Number of attribute names in LIST = 999.
   U_LINESZ:Page width in printing =272.
   U_PARASIZE:  Paragraph name and its parameter size = 256.
   U_LPCMD: System spooler name =   NT Spooler.
   U_MAXPROMPT: Number of prompts allowed in paragraph =  60.
   U_FSIZE: Dictionary field name size =31.
   U_MAXVALUE:  Number of values WHEN can handle =  10240.
   U_MAXBYEXPVAL:  Number of values BY.EXP can handle =  10240.
   U_SENTLEN:   Maximum sentence length =   9247.
   U_PROCBUFSZ:  Proc buffer size = 8191.
   U_NIDES: Maximum number of virtual fields in query=  256
   ...which indicates there's a limit of data allowed in the "WITH"
clause(s)
   of  256.   The UniData documentation says these parameters are
__NOT__
   configurable.   How  in  the  world  are  other people overcoming
this
   limitation?  Doesn't anyone want data for more than 256 somethings?
Is it
   possible  for  me to overcome this limitation without going into
1,000
   programs to split large numbers of ECL queries?  Or am I forced to
count the
   "somethings" available to submit to any query and abort if its more
than
   250?  Am I forced to split up A/P check runs (and many other
processes) into
   two or more runs to accommodate this limitation?
   Any experience, or thoughts, on this will be appreciated.
   Bill
---
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 LIMITs

[Kevin King]

There have always been limits on how big or complex a selection statement
can be.  And as best I know, these things are not configurable.  So... you
have to be creative on how you select the items.

For example, if you know the keys to the records of the customers to select
- or can build the keys based on the client number - you should be able to
take that list and use a FORMLIST to select those records directly.  On the
other hand, if the CLIENTNO field is a data field in the record and a SELECT
is absolutely necessary, you may need to create some preprocessing code that
selects all of the records in the file and if a record matches your
critieria, write it to a work file or a list in memory that can then be
selected or FORMLISTed.

With SUBR(..) type dictonaries, the possibilities are actually pretty
remarkable.  For example, create a routine that takes the list of CLIENTNOs
that you know and have those values put into a named common variable.
Create a SUBR(..) type dictionary using the same named common that returns a
Y/N as to whether that record is a candidate based on the list in common.
Then change your select to select any records where that field is "Y".  The
select command is well within limits, and you can put as many millions of
data elements in that list that you want, performance notwithstanding.

-K
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] UniData LIMITs

[Bill Haskett]

   We have a report writer that allows users to select the client they want to
   print any report for.  This subroutine builds a list of clients available to
   any particular user and uses this list to either compare against the clients
   entered or of all clients are selected then the entire list is used.  When
   this list is placed in an ECL query and executed, e.g
   SELECT CUSTOMERS WITH CLIENTNO = "1""2""3""4".
   ...all has been fine for years.  We picked up a new customer who has over
   300 clients.  When a user tries to run a report for all clients accessible
   by them the query aborts with...
   WITH condition stack overflow
   A quick look at "LIMIT" shows:
   :LIMIT
   U_MAXFNAME:  File name limit =   198.
   U_NAMESZ:Record id(key) size =   126.
   U_SELEMAX:   Number of select list = 10.
   U_MAXDATA:   Number of DATA statement =  500.
   U_HEADSZ:HEADER/FOOTER length =  2120.
   U_MAXHASHTYPES: Number of hash functions =   3.
   U_MAXSORT:   Number of sort fields(BY...) in LIST =  20.
   U_MAXWITH:   WITH stack size =   256.
   U_MAXWHEN:   WHEN stack size =   60.
   U_MAXCAL:Number of SUM+AVG+PCT+CAL in LIST = 54.
   U_MAXBREAK:  Number of BREAK.ON+BREAK.SUP in LIST =  15.
   U_MAXLIST:   Number of attribute names in LIST = 999.
   U_LINESZ:Page width in printing =272.
   U_PARASIZE:  Paragraph name and its parameter size = 256.
   U_LPCMD: System spooler name =   NT Spooler.
   U_MAXPROMPT: Number of prompts allowed in paragraph =  60.
   U_FSIZE: Dictionary field name size =31.
   U_MAXVALUE:  Number of values WHEN can handle =  10240.
   U_MAXBYEXPVAL:  Number of values BY.EXP can handle =  10240.
   U_SENTLEN:   Maximum sentence length =   9247.
   U_PROCBUFSZ:  Proc buffer size = 8191.
   U_NIDES: Maximum number of virtual fields in query=  256
   ...which indicates there's a limit of data allowed in the "WITH" clause(s)
   of  256.   The UniData documentation says these parameters are __NOT__
   configurable.   How  in  the  world  are  other people overcoming this
   limitation?  Doesn't anyone want data for more than 256 somethings?  Is it
   possible  for  me to overcome this limitation without going into 1,000
   programs to split large numbers of ECL queries?  Or am I forced to count the
   "somethings" available to submit to any query and abort if its more than
   250?  Am I forced to split up A/P check runs (and many other processes) into
   two or more runs to accommodate this limitation?
   Any experience, or thoughts, on this will be appreciated.
   Bill
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/