We have a couple of files in our system where the indexes are not updating. We enter data into the screens and save the records. Regardless of how long we wait the indexes do not update. We have tried to force the action by using the update_index("filename",",") routine in the write event (just after)the save. The index still does not update. The only way the index updates is when we rebuild the index …and rebuilding the index on the write using the update_index is not an acceptable solution. We feel that we should not have to rebuild an index every time there is an update and multiple people rebuilding the same index at the same time could potentially cause a problem.

We are currently running OI 9.0 using the UD 3.0.0.3 on a Win 2003 server.

The indexes (relational, btree and cross reference) are working perfectly on more than 15 tables, but are not working on 2 tables(relational and cross reference).

Does anyone have any insight into why this problem is occuring and/or any solutions that could fix this issue?

Thanks,

Emily Dotsias

What is the "Delay before indexing setting" for your application? You can find it in the "Database Manager" window and click "Database -] Environment settings…" Look at the "Indexes/Reports" tab.

How many workstations use this application and do you have dedicated index workstation?

Hi Jared –

Thanks for the response. We have forced an “update” index manually through the database manager and the index for the file in question does not update. We also have implemented an index flush every time we save a record via the update_index("filename",",") routine. This updates the index every time a record is saved. The index still does not update. We have waited up to 10 minutes and the index does not update. Therefore, we concluded that the problem is not the delay. It’s something else. Maybe, file related since the problem is limited to only 2 files. The only way we have found for the index to update (acknowledge a new record or a change to an existing record) is to “rebuild” the index either through the database manager or a parameter in the update_index routine. We don’t feel rebuilding an index is a suitable solution as it may cause issues if 2 or more users are rebuilding an index for the same file at the same time.

To answer your questions, the file delay is set to 5 seconds and we are still developing the application so we do not have a dedicated indexing workstation at this time. We have 1 or 2 developers working on the application at the same time and we are allowed a maximum of 3 simultaneous developers.

Thanks.

Emily

Hi Emily,

Have you tried deleting the indexes, ensuring the !file has been removed and SI.MFS removed from the data table and re-creating the indexes rather than forcing a manual update. If there is a problem with the index file creation this should resolve it.

Simon

I would agree with Simon's suggestion. Verify that when you remove the indexes from the table the table that begins with "!" is removed from the list of attached tables.

Does anyone develop directly from the server? If not, on the server right click "My Computer -] Manage". Choose "System Tools -] Shared Folders -] Open Files". Do you see any files ending in .LK or .OV listed?

Emily -

The index not being updated was created in the same environment, I mean using the same localization parameters (ASCII, CM_ISO, etc. in field of the SYSENV LND_xxx record loaded by the user trying to update the index), as the other indexes, isn't it?

- Stefano

Thanks for the responses. We have removed and added back the indexes. We also make sure that the “!filename” is removed when all the indexes have been removed from the file before we add the indexes back. We have even gone a step further and deleted the file all together and then recreated the file (same filename) and re-entered in the dictionary items from scratch, copied the data over, then re-indexed the file. Still the indexing issue persists.

We do all our development on workstations, no one does development directly on the server. We did the "My Computer -] Manage". Choose "System Tools -] Shared Folders -] Open Files". And we do see any files ending in .LK or .OV listed. However, they are AREV files from a separate application that is sharing the server. The UD is also installed on that server.

I would like to add that other indexes are working perfectly. Just two tables are not working.

Would it make a difference if the tables were created in OI8.x vs OI9.X?

We do all our development on workstations, no one does development directly on the server. We did the "My Computer -] Manage". Choose "System Tools -] Shared Folders -] Open Files". We do see files ending in .LK or .OV listed. However, they are AREV files from a separate application that is sharing the server. The UD is also installed on that server

I am not sure what you mean by “The index not being updated was created in the same environment” … We looked into the SYSENV and are also not sure how localization parameters (ASCII, CM_ISO, etc. in field of the SYSENV apply. What do you mean LND_xxx? All the LND_’s seem to be the default or languages and are not sure how LND’s have an impact on one table not updating an index. Can you please clarify?

Thanks.

Emily-

Let's say you created the (faulty) index prior to OI 9.0. Let's say also that the user creating the index was assigned, for some reason, either programmatically or by editing the corresponding SYSENV row, a LND_ record other than LND_DEFAULT. If you were still on OI 8.n the index would update properly - when upgrading to OI 9.0 the localization parameters do only come with partially - in this case you have to fix it manually within the Database Manager -] Database -] Environment Settings -] Localization -] Use LND -] select the value you need

- OR -

recreate the index, as others wisely suggested. The important thing to keep in mind is that the LND_ parameters used for creating, updating, and using an index must always match.

Hope it helps,

-Stefano

View this thread on the forum...