(Lurking Newbies: I hope you are reading this thread. This can sting you really HARD!, as Martin Phillips cites at the bottom. (meaning the "bottom" of this post being where MP's comments are, not where you'll get stung. Well, maybe...) The issue is this: the path to the index is hardcoded in the header of a data file. So if one uses OS-level, UV-unaware methods of moving files around, the wrong files point to the wrong indexes. Classic example is copying (cp, xcopy, etc.) a live file to a test area and the test area's version still points to the primary index. Both live & test files update the same index. SET.INDEX command is the cure. )
---- Glenn, I always thought the directory structure idea made sense. Sometimes one wants to move primary & indexes to separate disks & controllers for load balancing, but that could be handled with soft links, the same as today one can move the various INDEX.nnn files to different locations. Practically (i.e. from user perspective) speaking, I don't see how adding backward links would make things WORSE. With or without such a link, one MUST do a SET.INDEX to realign the primary and secondary. SET.INDEX itself might be a tad more complicated, a 2-way street rather than just 1. cds -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Herbert Sent: Monday, August 02, 2004 3:31 PM To: [EMAIL PROTECTED] Subject: RE: [U2] RE: Copying data between two Universe servers Funny you mention this. Back in 1994-95 when I was rewriting all the low level indexing code, we tried to figure out some way to do exactly this, putting some type of full path or such within INDEX.MAP to point back to the main file. Problem is, we couldn't figure out a way to safely do this as indexes would then have the same issue where you'd have to use SET.INDEX or something like it to "reset" where the main data file existed if you moved the indexes (which many sites did and probably still do). The chances of either the main file or the indexes getting lost got worse! The way I really hoped would be implemented was to have the index files exist within the file subdirectory, i.e. all files with indexes would be similar in structure to Type30, but have a .index subdirectory within them. So, from then on, the indexes would be "tied" to the main data file. If you moved the file sub-directory, the indexes would be moved automatically (well, assuming you did THIS part correct!!). As you can tell, that never made it anywhere. At 03:04 PM 8/2/2004, you wrote: >IBM could help us here by writing a backward link in the I_INDEX.MAP >that says where the primary file is that the index supposedly >references. If there is a mismatch, error out. > >Is there a situation where the current state, where more than one >primary files could point to the same index is a "feature"? > >cds > >-----Original Message----- >From: Martin Phillips >Sent: Wednesday, July 28, 2004 2:28 PM > >Another trap for the unwary.... > >If you use an operating system copy program to move a UniVerse file >that has alternate key indices, the index subfile pathname stored in >the file header will not be updated. You may need to use SET.INDEX to >correct this after the copy. > >I know of one major UV user who copied a file to a test system in this >way and later discovered that updates were adjusting the indices on the >live system across a network. I never heard what this did for their >business! ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
