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/
