Index is out of date как исправить
Профиль
Группа: Экс. модератор
Сообщений: 4147
Регистрация: 25.3.2002
Где: Москва
Репутация: 80
Всего: 162
Database index out of date error
This is a BDE/Paradox error message. For newbies, BDE error messages are daunting, cryptic messages. Actually, even for seasoned veterans, they can sometimes be real "stumpers." Unfortunately, there's no real good reference available that I know of, so all I can offer with respect to this error message is my experience.
The "Index out of date" message can mean a couple of things:
1. 1. One of the more common causes of this error is one in which you have a couple of copies of a table existing on your network or machine. For instance, when I develop applications, I have my application tables residing in my development system, then have copies of them on my network. When I need to update my tables, I usually do the updates in my development system, then copy them over to my deployment system on the network. I've run into this exact error when I've copied only the table (.DB) file and not its accompanying index file(s) (.PX, .X01, .Y01, etc) as well. You see, when you update a table by changing it in any way, its index files are also resynched to reflect the changes. So if you copy just the table to a new place on your system and don't include its family members, you'll index files that aren't in synch with your table. Okay that's one cause.
2. 2. The next cause could be just this: One of your indexes is corrupt. This could be due to sector errors on your hard disk, or the rare, but possible, direct corruption of an index. This usually happens if your program abended while performing an update to a table with an index of some sort. In that case, the index doesn't get updated.
But in any case, the only way I know of to correct the problem is to do the following:
1. Open up your table in Database Desktop.
2. Restructure it.
3. Define/Rebuild all your indexes.
4. Save the file.
BLOB has been modified., Index is out of date
Объяснение от Борланд:
Index out Date ($2F02) is an error that occurs while using Paradox tables when the data in a table and a corresponding index is not consistent. In most cases (see below for the one exception), short of malicious behavior such as renaming an index, adding some data to the table, then renaming the index back, there is no programmatic way to cause this error to occur. There is no way to determine which index is out of date. All indexes must be recreated.
Blob has been modified ($3302) is an error that occurs when the Blob portion of the record contained in the .DB file has become inconsistent with the Blob portion in the .MB file. This could occur when the write to the .DB file was successful but the .MB file did not get updated, or visa-versa.
There are a few mechanisms to fix a table where these errors have occurred.
1. First try re-starting the application. It is possible that the BDE has become unstable and is reporting incorrect errors. Also try opening the table with a different application.
2. Use Paradox 7 or 8 to run the Table Repair utility. Please see original documentation for more information.
3. Run TUtility and rebuild the table. TUtility is an unsupported utility available for download from the Borland web site in the
4. Delete all indexes and recreate them (Index out Date ($2F02) error only). To do this you'll need to know the structure of all your indexes (including primary) before recreating them, which means you need to know the structure of all indexes before the error occurs.
There are 8 known possible causes for this error.
1. Incorrectly setting the LOCAL SHARE property.
Most commonly this occurs via Peer-to-Peer networking. In this case the two different database engines are on two CPUs, even though they may be the same version. See < BDE setup for Peer-To-Peer(Non-Dedicated) Networks>for additional information on Peer-to-Peer setup.
Another condition is when two different database engines execute on the same CPU concurrently and access data locally. This would be true when any combination of following are used concurrently: The Paradox Engine, BDE 16 bit, BDE 32 bit, Paradox for DOS. In this case each engine must set LOCAL SHARE to TRUE. Note that if use two applications which both use the same database engine (for example: Delphi 3 and C++ Builder 3) concurrently are run LOCAL SHARE does not need to be set to TRUE. In this case, all locking and cached data is in a central memory pool which all BDE applications have access to. Also, if two different database engines use data remotely, LOCAL SHARE must be set to TRUE.
Code should be used at startup to check the setting of local share. Look at the
2. Error transmitting data from the workstation to the server.
Most commonly, this occurs with bad network hardware (cable, card, hub, etc.). This has been determined to be a problem even though there were no other errors are detected in data transmission. To determine if this is the cause for your error, try eliminating one CPU at a time from using the data and see if the problem continues.
3. Bad VREDIR.VXD on any client accessing tables Windows 95 ONLY:
Several versions (notably 4.00.1113 and 4.00.1114) of the file VREDIR.VXD may need to be updated.
Reports have shown that using the original release of VREDIR.VXD (4.00.950) and a new release (4.00.1116) do not result in the errors "Blob has been modified" and/or "Index is out of date." If any one of the clients has a "bad" version of this device driver, the error can occur on any machine, not just the machine with the bad driver.
This error most likely occurs in 16Bit versions of the Borland Database Engine, although it still can occur in 32Bit versions.
For further information on the update of VREDIR.VXD, Please check the following Microsoft Articles:
4. For Windows 95 clients only, when using data on Windows NT: Add the following key in your registry: HKEY_LOCAL_MACHINESystemCurrentControlSetServicesVxDVredir
Then create the string or Binary Value (either one works) with a name of DiscardCacheonOpen and make it equal to 1.
Note that this an undocumented registry entry obtained from Microsoft. Questions on its functionality should be directed to Microsoft.
5. Problem with opportunistic locking Windows NT ONLY: Try turning off opportunistic locking in the Windows NT registry: See Microsoft Article
Note: Borland internal testing has not indicated this setting to be significant. However, some Borland customers have indicated this to solve the problem.
6. Improperly closing files such as due to loss of power or restarting a workstation or the server without closing files first may cause this problem. Paradox tables are not designed to withstand such behavior. If this is a possibility in your environment, we recommend you use a Client Server database that can recover from such conditions.
7. Extremely large numbers of indexes, especially involving Referential Integrity can cause this problem and especially when using Windows NT as the server. Borland recommends using a Client Server database under this condition. However, if you are using Windows NT as your server, switching to Novell Netware or Windows 95 as the server may resolve the problem as well.
8. The one programmatic way you can make this error occur is if you attempt to post a duplicate value to a unique, non-primary index at the same time you attempt to open the same table. This problem only occurs if local share is set to False and only occurs on local drives.
Unverified solutions
1. Windows 95 Only: Bring up the network properties screen on all Workstations and enter the netBEUI properties screen. On the advanced tab, make sure that "Set this protocol to be the default protocol" is checked.
2. Windows 95 Only: If the previous suggestion did not work, try removing the following protocols in order. Remove one at a time and then re-test your problem:
1. NETBIOS support for IPX/SPX-compatible Protocol
2. TCP/IP
3. IPX/SPX-compatible Protocol If the problem disappears, attempt to add back in all protocols except for the last one that was taken out. Again, make sure netBEUI's default protocol check box is checked.
3. Windows NT Only used as a Workstation: On the Network Bindings page of the Network Properties, set the NetBEUI Protocol to be at the top of all services. The TCP/IP stack is known for having a lot of overhead that might cause timing problems. Since NT will send requests back in the same protocol as it is sent, changing the bindings on a NT machine used as a server will have no effect.
Other resources
1.
Примечание от Vit:
Обычно такие ошибки возникают из-за проблем с кэшированием измений в базе данных, особенно при использовании BLOB/Memo полей и особенно при многопользовательском доступе. В простейшем случае снизить частоту возникновения этой ошибки на несколько порядков помогает вызов метода FlushBuffers после каждого изменения таблицы:
| Код |
| Table1.post; Table1.FlushBuffers; |
Это сообщение отредактировал(а) alex-co — 24.7.2004, 06:38
Профиль
Группа: Завсегдатай
Сообщений: 1292
Регистрация: 4.8.2003
Где: г. Самара
Перестал открываться на чтение файл БД ПАРАДОКС
в филиале установлен регистратор учета рабочего времени
пишет в бд ПАРАДОКС
копирую *.db в каталог на машину в головном офисе
из db-шек делаю выгрузку в 1с82 обычноне приложение
через com
при выполнении модуля 1с82 перестали открываться на чтение два файла *.db
пытаюсь открыть эти файлы борданд десктопом , говорит: » index is out of date «
если эти файлы открывать не в каталоге, а копировать изолировано от общего каталога — и десктопом открываются, и модуль 1с82 работает
БД = Новый ComObject(«ADODB.Connection»);
БД.CursorLocation=3;
//ПутьБД=»c:\data»; — это 3 месяца работало
//все сваливал в каталог DATA
ПутьБД=»c:\111″; //—это сейчас проверяю
//если деражть в нем только 2 этих злосчастных файла,
//будет работать
Если БД.Open(«Driver=
Сообщить(«Ошибка. «);
Возврат;
КонецЕсли;
открывал со своей машины борланд дестопом эти *.db в рабочем каталоге программы регистратора рабочего времени на машине удаленного филиала
(через маршрутизатор, они в разных сегментах ЛВС) -открывается
Index is out of date как исправить
"Index out of date" How do I fix this? I have a Windows 2000 based voicemail server on our phone system called MVX-Futura Macro Voice Voicemail. The company has gone out of busiess, so there is no support options there. The power blipped three times in row the other day and even though we are on a battery backup, when the blips were over the voicemail wasn’t working. Upon logging in to the server, there was an error on the screen: "Index out of date" and a path to a file inside the voicemail program C:\MVXFutura\DataStru\Nfyinst.db . I navigated to the file, but it has a .db extension which I now know means "database". I am pretty new to programming, so I did some digging. It seems that the file (or file system as I now know it) may be repairable, but the first step is to open it which I can’t seem to do. I’ve tried Access 2010, but my resources beyond that are few. This brings me to my questions.
1. Can the file be repaired without reinstalling the program because I can’t find the disc?
2. If it can be repaired, then how do I do it? I read a bunch of posts about rebuilding tables or indexes or something? It seems this error comes from the file having a modified date that doesn’t match a table somewhere else, so it sounds like an easy fix?
3. Does anyone know what program may have been used to create the file so I can know what I need to open it, or does anyone have a slew of programming programs that they could possibly use to try to figure out what would open it? I have the file copied to a flash drive so it could be supplied. I’m guessing that if the system is quite a few years old then maybe that would narrow down the possibilities of what created it and someone at Microsoft might know what that program is since it worked with Windows 2000?
I tried just deleting the file from the folder to see if the program would recreate it, but no dice. The closest thing I got to seeing the file was when I set the encoding to "Unicode" and got a whole bunch of chinese looking characters, but still some odd ones mixed in. Any help or advice on this topic would be greatly appreciated, but if this is a lost cause I would like to know so I can quit wasting my time. Thanks in advance.
'Index out of date'
No way!
And by the way, new millenium starts on January 1st 2001, not 2000!
hello milicicd, how about your last q : "Multiple accesing of Paradox table"
and about index out of date, that's the beauty and the beast of paradox table 🙁
but you can find a good paradox repair util vcl for you in : http://korzh.hypermart.net it's freeware and with source code.
and good resource and sample code for your problem in : http://www.borland.com/devsupport/bde/delphifiles.html
two possibilities, why the index comes out of date,
one client ended abnormally
the secondary indexes are not created with update-service
ps.: i missing the right word in english for update-service (in german: gewarteter Sekundär-Index)
have you tried it yet ?
i'm not sure what *.val is(may be someone here can help), but some error didn't come up again after i delete this files.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
GET A PERSONALIZED SOLUTION
contains column-information for a view of a table in the Database-Desktop or paradox self, like column-width, formatting-information, column-order etc.
*.val are not applicable with delphi-programs.
you can repair the index byself,
without any additional tools.
how?
here is a sample for use with indexname,
if you use indexfields i can code a sample for this too.