Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 20 AUG 2004 10:54:27PM Ray Chan wrote:

I need to rebuild some indexes in OI7.

I recently converted from OI4.13 to OI7.01. Now that I have I remember encountering this index problem during the beta for OI7. (FS404 means the system thinks that I'm trying to attach another vol with the same name, but I'm attached to it already.) Because of this I delayed my upgrade to OI7. Must be AGE and too much beer that made me forget. Anycase I bit the bullet and did my upgrade to OI7. I guess I was blind by "No More OIPI.exe."

I remember during the Beta for OI7 that MikeR or someone posted a workaround (???), but I'm hazy here and at the moment the Beta site for me at least is not accessible to search and see what advise was given during the beta.

I saw a reference that the volumeID can be changed, but I'm afraid to do this because of possible reprecussion to my indexing later. Does anyone care to comment on this?

I Need to rebuild indexes in OI7. Need to find a solution SOON. I really don't want to rollback to OI4.13 after all the stuff that I went thru. A workaround would be acceptable.

Thanks….

Ray Chan

P.S. I'm sure most people don't see this problem. Am I seeing this because I converted from AREV 2.0x to OI? If others are seeing this, how are you avoiding this.


At 23 AUG 2004 04:25AM The Sprezzatura Group wrote:

There are some issues with relative pathing and how OI handles it. OI 7 seems to qualify the path, so if you attempt to call

ATTACH_TABLE '..\UPDATES\22AUG04' it will attach "S:\DATA\UPDATES\22AUG04'.

Probably, you have some relative paths in your DBT. You'll need to change them to match what's being used by the index routines.

The Sprezzatura Group

World Leaders in all things RevSoft


At 23 AUG 2004 10:29AM Ray Chan wrote:

Dear Mr Sprezz:

There are some issues with relative pathing and how OI handles it. OI 7 seems to qualify the path, so if you attempt to call…

There should be no relative path in our application DBT as I'm using the Sysprog DBT.

We do have an attach routine that is run when our application start. It attach_tables using the relative path, i.e., Attach_Table "..\Example\". However, I believe that I earlier changed the shortcut to call the "real" drive, e.g. "C" vs. "O", and I still saw the FS404 message. If I did this, wouldn't the indexing routine use then use the absolute path?

Okay here are a couple of questions: You said: Probably, you have some relative paths in your DBT. You'll need to change them to match what's being used by the index routines.

Let's assume we do have some relative path. 1) How do we determine what path the index routines are using? 2) Do we need to keep using the same path to ensure that our indexes stay current and continue to function correctly in our application. I ask these two questions because we just notices a situation. That is, after it looks like we fix some indexes, our batch process runs but then they fail again unless we rebuild certain indexes again. I'm not sure if this is an OI7 indexing issue, but we have only started noticing this problem after we did our conversion. It could be corrupt data somewhere (unnoticed in OI4.13), but again with this "matching" path issue and problem of using relative path in OI7 could this cause some indexes to not get updated properly during normal processing?

Also, do you know if this issue will be addressed by RTI? RTI?

Thanks,

Ray Chan

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/13949234af17e56785256ef7000ff8f5.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1