Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Index problems

Status
Not open for further replies.

adale

Programmer
Apr 18, 2001
48
GB
I am experiencing loads of issues with indexes breaking on heavily used tables. Is there a known bug that requires indexes to be rebuilt almost on a daily basis?
 
What size are the tables?

What BLOCK size are the tables?

Do you have oplocks turned off?

How about write cache on the HD the data resides on? (The OS doesn't always allow this.)

Tony McGuire
"It's not about having enough time. It's about priorities.
 
Worst offending table is 308k. It has a primary and secondary index and 3 lookups too.
Next worst is 8,316k.

Block size is at the default 2048
 
OK. Sizewise you aren't even close, even with 2k block.

I'd check opLocks settings.

As well, make sure all machines have Local Share = True in the BDE.

Is this a shared data environment?

If so, what OS is the server? And is the server dedicated, or a workstation as well?




Tony McGuire
"It's not about having enough time. It's about priorities.
 
The whole thing runs on a desktop PC with WinXP.
I'bve just found out that it's 2 service packs out of date so am updating that first.
The user either runs a VB app to populate the database, or goes into Paradox itself and uses forms & reports.
Normally they would use each method exclusively, but recently they may be opening both at the same time which makes me think of write conflicts.

Where does opLocks reside?
 
opLocks is a setting (or 2, depending on OS and what the machine is doing (server, server/workstation) in the registry.

Copied article at with a link to the actual M$ article.

VB? Well, I'd certainly go to that code and ensure things are being done properly. And that a correct ODBC driver is being used; some versions from M$ don't support proper editing, and some don't support editing beyond Table Level 5.

Tony McGuire
"It's not about having enough time. It's about priorities.
 
I think I've found what part of the problem is now.
The production files are moved to a reporting server and in that process one of the .val files wasn't getting updated. I totally refreshed the report server copy of the files and am not getting the error so much now.
I've also stopped the vb app and Paradox db being used at the same time.
Re the ODBC driver, we use Paradox's as Microsofts doesn't support any sort of sharing.

Thanks for your help.
 
"...am not getting the error so much now."

Does this mean you fixed the error, or you are still getting it 'sometimes'?



Tony McGuire
"It's not about having enough time. It's about priorities.
 
As luck would have it, I did get the error again after I wrote that email.
Then I found some further email therads that said the .val file related to the bad tables can sometimes get confused.
They can be deleted and will get recreated by the database automatcally. Since I deleted those .val files I haven't had any more issues.......so far.
 
(1) Make sure that all indexes are marked "maintained." If not they immediately are considered "out of date."

(2) Make sure that all tables related to this one have the same "table language." If, for example, table-X is French and table-Y is US_ASCII, you'll always have problems.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top