I forgot - another side effect of this is that, if you declare an index on one partfile, it makes sense to declare it on all.
I'm sure one of the VMark/Ardent/IBM guys who worked on this will muck in and confirm the details, but if you try doing a select or sorted list or whatever on a distributed file, and some of the partfiles have indices and some don't, it can give the list engine a real headache trying to work out how to optimise the query ... Cheers, Wol -----Original Message----- From: Anthony Youngman Sent: 10 February 2004 12:05 To: 'U2 Users Discussion List' Subject: RE: Secondary Indices on Distributed Files Except it's not a strange reason. The whole point of a distributed file is that any part of the file can be treated as a file in its own right, so it needs its own dictionary. And given that MV makes no distinction between data and dict portions at the structural level (and all that jazz), there's no reason why you can't have one dict portion serving every data portion. Beats most SQL databases I know of, where you can't point one definition table at several data tables, despite Codd&Date saying that relational (like MV) isn't allowed to draw any fundamental distinction between data and the definition of that data. Index handling in distributed files is funny, but it makes perfect sense once you understand how DATA/DICT and distribution all fit logically together. Jump in with a superficial overview and you'll be well puzzled, look at it in depth and you'll understand how neat it actually is, and where it seems messy (as indeed it is) the alternatives are actually ten times worse ... Cheers, Wol -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 09 February 2004 20:37 To: [EMAIL PROTECTED] Subject: Re: Secondary Indices on Distributed Files For some strange reason, the DICT of each Part File needed to contain copies of the I-Types from the Distributed File's DICT in order for CREATE.INDEX to work correctly. Next question... To avoid having to copy DICT items to all the Part Files each time a change is made, I updated the VOC pointer of each Part File to look at the DICT for the Distributed File. This seemed to work fine for the CREATE.INDEX, and each INDEX.000 record within each of the I_files (one for each Part File) has correct index information for the records within it's part file. >From a Distributed File perspective, does anyone see a problem with changing the DICT pointers for each Part File to look at the DICT of the Distributed File? Each Part File belongs to only this one Distributed File. If not, then how about the Indices themselves when combined with Distributed Files? Would each Part File not using it's own DICT cause a problem? Thanks! [EMAIL PROTECTED] group.com To: U2 Users Discussion List <[EMAIL PROTECTED]> Sent by: cc: u2-users-bounces@ Subject: Secondary Indices on Distributed Files oliver.com 02/09/2004 12:08 PM Please respond to U2 Users Discussion List I've got a Distributed File that I'm trying to create indices on. Four of the fields are D-Types, and CREATE.INDEX runs fine for them. Three fields though, are I-Types (that are compiled and working), where CREATE.INDEX gives the following error: I-descriptor must be compiled before execution. I-descriptor must be compiled before execution. I-descriptor must be compiled before execution. Program "*UVPRINTMSG": pc = 34, Variable previously undefined. Zero length string used. [000000] All seven fields are working just fine as indices on the original file that was a Static Hashed file. I'm setting up the Distributed File to get around the 2GB limit issues. Does anyone know of any limitations putting secondary indices onto distributed files? Thanks! Gary Canedy ----------------------------------------------------------- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users ----------------------------------------------------------- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users *********************************************************************************** This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. *********************************************************************************** -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users