Well, when I read that comment about READNEXT having to return file as well as key - actually it *already* returns a lot more than just key - try doing a SELECT WHEN.
I guess partfiles would be easier - the problem with partfiles (and I hit this in my last job) is that the database must be able to determine the relevant part based on @ID alone. That's sometimes easier said than done, and in the cases being discussed I suspect that may be the case ... I'm trying to write something about MV design, and this is a fundamental design thingy - MV needs a primary key where SQL doesn't. I'm with those people who say "just have a huge file". That's what you should do in relational, and heaven knows MV files tend to be smaller (and faster) than relational for the same quantity of data. Cheers, Wol -----Original Message----- From: David Wolverton [mailto:[EMAIL PROTECTED] Sent: 16 May 2007 19:47 To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UD] Union Query We know that's the CURRENT fundamental design... We're talking an extension to that design for those who would find it useful. I never use many parts of UniData - should those be removed because I don't see the need? <g> The issue is that UniData (where we all are) does NOT have a PartFile. If we had PartFiles, that would address exactly the issue we speak of - the ability to segregate data but retrieve it as one logical file. Adding PartFiles to UniData would remove the need for a multi-file SELECT/LIST (MSELECT and MLIST?) -- Which would be easier to implement by IBM? David W. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Schasny > Sent: Wednesday, May 16, 2007 12:21 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UD] Union Query > > I vote no. The UV/UD query language is fundamentally designed > to work against one file with correlatives/I-types pointing > to any other tables from which we require related data. This > is something at the core of our environment. The problem here > is, shall we say, problematic database design. ------- 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/
