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 <[email protected]>
Sent: 1/29/2009 9:04 PM
To: [email protected]
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: [email protected]
[mailto:[email protected]] On Behalf Of Marc Harbeson
Sent: Friday, 30 January 2009 12:24 PM
To: [email protected]
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: [email protected]
[mailto:[email protected]] On Behalf Of Bill Haskett
Sent: Thursday, January 29, 2009 7:12 PM
To: [email protected]
Subject: Re: [U2] UniData LIMITs
That's correct.
Bill
______________________________________________________________________
From: Kevin King <[email protected]>
Sent: 1/29/2009 2:37 PM
To: [email protected]
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
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
