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.comTo: 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. [00] 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
Re: Secondary Indices on Distributed Files
Sorry, forgot to mention: UniVerse 9.5 on AIX 4.3.2 [EMAIL PROTECTED] group.comTo: 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. [00] 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
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 CoddDate 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.comTo: 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. [00] 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
RE: Secondary Indices on Distributed Files
There's a few postings on this very topic in the archives, such as this from Glenn Herbert... http://www.indexinfocus.com/dl/u2list/200106/15105.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 7:37 AM 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! -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
