Re: [U2] [UD] disconnected index
Thanks to everyone who responded to my post. I will DELETE.INDEX ALL and recreate and rebuild them. It must have been related to something we did at the OS level, though I am not exactly sure what that was. Thanks, Josh [EMAIL PROTECTED] wrote: Josh Marcus wrote: Has anyone ever seen a UniData file have its index become disconnected from the data file? I have a file that used to have indexes. I can verify that because I have a LIST.INDEX printout from a few months ago showing them. However, they are no longer in place. When I run LIST.INDEX against the file, it reports there are none. I checked at the Unix level and there was still an index file (X_TX.ARCHV) next to the data file. Not knowing what else to do, I tried to add one of the indexes back to the file. I got this: CREATE.INDEX TX.ARCHV TXA.CAMPAIGN TXA.CAMPAIGN: can not create multiple indices on same location After that, the index showed up in LIST.INDEX. Furthermore, LIST.INDEX tells me the index is built, and selections on the file behave like there are built indexes in place. Anyone have any ideas as to what's going on here? Should I be concerned? The file in question is a dynamic file, if that is of any relevance. System info: UniData 6.0.11 on Tru64 Unix 5.1a. The index for a dynamic UniData file is not stored as X_file. Instead, the index is stored in idx00n partitions inside the directory that holds the primary and overflow partitions. Is it possible that someone converted this file to dynamic recently and the index conversion part of the process didn't go through properly - maybe because of permissions? I've seen scenarios where over zealous system administrators imposed a 0111 umask which meant you could create a new directory for a dynamic file, but couldn't subsequently do much with it because you couldn't list its contents! Anyhow, the X_TX.ARCHV is certainly not related to any indexes on TX.ARCHV if TX.ARCHV is really a dynamic file, in which case TX.ARCHV will be a directory at the OS level. You CAN disconnect an index from a file but leave the OS index files in place, but you either have to have some file corruption, or someone playing cleverly (or stupidly) with fileview. I'd strongly recommend you check the VOC pointer for TX.ARCHV and make sure that the one you are looking at at the OS level is the same one being accessed when you are inside UniData. I'd then check if it really is a dynamic file, and if so, then simply rename your X_TX.ARCHV as something which will remind you to delete it after a day or so. Then run guide against the file to check for any corruption, fix that up with fixfile, and then re-address the indices question. If LIST.INDEX shows you that there really is an index, run guide_ndx against it and consider doing as Colin suggests and DELETE.INDEXing everything before CREATE.INDEXing them again. Cheers, Ken --- 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/
[U2] [UD] disconnected index
Has anyone ever seen a UniData file have its index become disconnected from the data file? I have a file that used to have indexes. I can verify that because I have a LIST.INDEX printout from a few months ago showing them. However, they are no longer in place. When I run LIST.INDEX against the file, it reports there are none. I checked at the Unix level and there was still an index file (X_TX.ARCHV) next to the data file. Not knowing what else to do, I tried to add one of the indexes back to the file. I got this: CREATE.INDEX TX.ARCHV TXA.CAMPAIGN TXA.CAMPAIGN: can not create multiple indices on same location After that, the index showed up in LIST.INDEX. Furthermore, LIST.INDEX tells me the index is built, and selections on the file behave like there are built indexes in place. Anyone have any ideas as to what's going on here? Should I be concerned? The file in question is a dynamic file, if that is of any relevance. System info: UniData 6.0.11 on Tru64 Unix 5.1a. Thanks, Josh Marcus University Relations, Information Systems University of California, Berkeley --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Can I change VOCLIB to DIR type file?
I am interested in changing our VOCLIB file (and other files we use to store UniQuery paragraphs) to a DIR type file. It is currently a hashed file. Is there anything I should be aware of when making this change? Will it cause any negative effects? We are using UniData 6.0.11 on Tru64 5.1a. Thanks, Josh -- Josh Marcus University of California, Berkeley --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Can I change VOCLIB to DIR type file?
Kevin King wrote: I can't say for certain that it would work at all, but if it did I would wonder if performance would be as good as a properly sized hashed file. Why would you want to change this to a directory? Hi Kevin, Thanks for your reply. I have tested this and found that it appears to work at least on initial inspection. In other words, I can put a paragraph into a DIR type file, create an R-type VOC pointer, and then run or PHANTOM the paragraph. I don't know what the performance impact would be. In the little bit of testing I did, I didn't detect a noticeable difference. The DIR-type file I used for the test has 1863 items in it. I'm not sure what else might be worth testing. Is there a specific usage scenario that you think might be prone to performance problems? In answer to your question, the reasons that I want to change our VOCLIB files to a directory are: - I want to use jEdit to edit the paragraphs. - I can see the date and time of last update of a paragraph. - I can use the unix find utility to identify paragraphs that have not been accessed in a long time to assist with clean up. - I can recover individual files from tape backup instead of the whole UniData file (date and time stamp on individual files would help here as well.) - I can apply Unix-level permissions to individual paragraphs to control access. - It would be nice not to have to keep resizing VOCLIB files. It's difficult to keep up with everyone writing paragraphs. I should note that in our environment we don't use the default VOCLIB file itself, but rather create a custom file (e.g., XJXM.VOCLIB) for each person writing paragraphs. Each file needs to monitored and adjusted. - Our voclib files tend to be hard to size. They also don't have even growth--people can quickly overflow the files by copying records in. Thanks again, Josh --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Can I change VOCLIB to DIR type file?
Thanks to everyone who responded to my post. Based on the information in your responses, I think this change will work for me in my environment here. Josh Original Message Subject: [U2] Can I change VOCLIB to DIR type file? Date: Tue, 16 Nov 2004 09:20:29 -0800 From: Josh Marcus [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] I am interested in changing our VOCLIB file (and other files we use to store UniQuery paragraphs) to a DIR type file. It is currently a hashed file. Is there anything I should be aware of when making this change? Will it cause any negative effects? We are using UniData 6.0.11 on Tru64 5.1a. Thanks, Josh -- Josh Marcus University of California, Berkeley --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
