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 <[email protected]> Sent: 1/30/2009 12:27 AM To: [email protected] 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 <[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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
