Ошибка blob has been modified

1. 15.02.2013, 11:07

   #1

   Ночью встала станция при загрузке базы на 20% выдавала «системная ошибка», залил свежую, все работало.. Сегодня делаем на сервере закрытие дня в r-keeper, процесс заканчивается ошибкой «BLOB has been modified», как востановить работу программы?

   ---

2. 15.02.2013, 11:09

   #2

   

   
   Разбирающийся
   

   ---

   выложите сюда содержимое endday

   ---

3. 15.02.2013, 11:30

   #3

   ---

4. 15.02.2013, 12:05

   #4

   

   
   Разбирающийся
   

   ---

   Порушились BLOB-ы в фалах OPERT.DB и OPERT.MB от второй кассы (папка 14-02-13.02)
   В этих файлах содержится кассовый протокол. Чинить их не вижу особого смысла.
   Поэтому же у вас и ночью ошибка была.

   Для того что бы день закрылся нормально положите в папку 14-02-13.02 чистые файлы OPERT.DB и OPERT.MB из дистрибутива.

   ---

5. 15.02.2013, 12:19

   #5

   У меня нет чистых файлов вроде как.. За информацию спасибо, хотелось бы узнать процесс определения битых блобов.. и как узнать не будет ли той же истории на следующий день, от чего они вообще сыпятся?

   ---

6. 15.02.2013, 12:39

   #6

   

   
   Разбирающийся
   

   ---

   Сообщение от vince
   

   У меня нет чистых файлов вроде как..

   Есть. Вы же ночью взяли где то чистый DATABASE. Вот от туда и возьмите чистые OPERT.DB и OPERT.MB

   Сообщение от vince
   

   хотелось бы узнать процесс определения битых блобов..

   Открываем файлы редактором (DBD32, DBTOUR и т.п.) и тыкаемся в каждое BLOB поле. Некоторые открываются, некоторые нет и дают вашу ошибку.

   Сообщение от vince
   

   и как узнать не будет ли той же истории на следующий день, от чего они вообще сыпятся?

   Узнать очень просто — надо прожить еще один день
   Причины по которым бьются файлы БД различны. Самая простая это в момент транзакции (записи информации в файл) отрубили питание станции. Так же это может быть связано с ошибками чтения/записи на жестком диске. Ошибками памяти. Расположением звезд на небосклоне и курса Мексиканского доллара по отношению к бивалютной корзине…

   ---

7. 15.02.2013, 12:53

   #7

   Еще раз спасибо за ответ! А отчеты не могут быть битыми из за неправильного копирования файлов DATABASE? я копировал все кроме файла system.db, но если есть вероятность того, что некоторые файлы не скопировались, станция все равно запустилась, но закрытие дня на менеджерском компе не происходит? или это только проблемы железа?

   Вот незадача, за два года работы, я впервые столкнулся с этой ситуацией, еще и ночью при полном зале народа

   Если я заменю файлы на чистые OPERT.DB и OPERT.MB, затем сделаю закрытие дня на менеджерском компе, у меня продажи упадут в очтеты или 14 число пройдет как день без продаж якобы?

   ---

8. 15.02.2013, 13:48

   #8

   

   
   Разбирающийся
   

   ---

   Сообщение от vince
   

   Если я заменю файлы на чистые OPERT.DB и OPERT.MB, затем сделаю закрытие дня на менеджерском компе, у меня продажи упадут в очтеты или 14 число пройдет как день без продаж якобы?

   С продажами все будет нормально. Ну будет данных по кассовому протоколу только по этой станции.

   ---

9. 15.02.2013, 17:05

   #9

   Есть мнение, что OPERT.DB OPERT.MB заменять чистыми нельзя, возникнут проблемы, какие могут возникнуть из этого проблемы?

   ---

10. 15.02.2013, 17:18

    #10

    

    
    ТВОРЕЦ СЧАСТЬЯ
    

    

    ---

    Сообщение от vince
    

    Есть мнение, что OPERT.DB OPERT.MB заменять чистыми нельзя, возникнут проблемы, какие могут возникнуть из этого проблемы?

    Написали же выше:

    Сообщение от sibgaba
    

    В этих файлах содержится кассовый протокол.

    Т.е. потеряете протокол за этот день. Но он и так потерян, файлы-то битые.

    Алексей Аркадьев

    Когда заказчик ищет волшебника, то чаще всего он находит сказочника.
    Если у Вас есть вопрос по поддержке — напишите его на форуме, я обязательно отвечу, если знаю ответ.
    Если Вам нужны какие-то файлы, пишите на почту: support@carbis.ru, но вначале посмотрите в разделе для скачивания.
    Для коммерческих вопросов:
    +7 (495) 740-49-91, или на почту: sales@carbis.ru

    ---

← →
Dolphin

  (2009-09-09 17:49)
[0]

После неудачного закрытия программы стало появляться окошко с ошибкой BLOB has been modified. Из файлов базы — у меня *.DB и *.MB. Как я понимаю картинки переводятся в двуичную систему и сохраняются в *.MB. Можно ли как нибудь теперь достать эти картинки оттуда?

← →
Виталий Панасенко(дом)

  (2009-09-10 09:05)
[1]

так достать картинку или вопрос в появлении сообщения?:-)

← →
Anatoly Podgoretsky ©

  (2009-09-10 09:37)
[2]

То есть таблица без первичного ключа и каких либо индексов.

← →
Anatoly Podgoretsky ©

  (2009-09-10 09:46)
[3]

Кстати в наше время это сделать тяжело, на Борланд убрали все — статьи и утилиты, а на Эмбаркадере не появилось, переход по ссылке на Борланда ведет на Эмбаркадер, а там сообщения что нету. Тут нужна Борландовская утилита по ремонту таблицы, а ее нет, как давно нет и Парадокса — продан Корелу, а Корела вроде тоже уже нет.

← →
Виталий Панасенко(дом)

  (2009-09-10 10:28)
[4]

Почему нет? есть DBDOCTOR — русскоязычный, в архиве TUTIL32.DLL и прога.. да и так найти можно и TUTIL.EXE/TUTIL32.DLL тоже на просторах Сети..

← →
Anatoly Podgoretsky ©

  (2009-09-10 11:45)
[5]

На просторах сети все можно найти. А вот попробуй найти на официальных сайтах.

← →
Dolphin

  (2009-09-10 18:50)
[6]

> так достать картинку или вопрос в появлении сообщения?:-
> )
</Достать картинки. Может есть какая нибудь функция в Delphi?I>

← →
Dolphin

  (2009-09-10 19:52)
[7]

Спс всем, кто помогал. База восстановлена с помощью DbDoctor на основе tutil32.dll Но записи в хаотичном порядке. Как можно (может быть програмно или другой программы) поменять местами как они были?

← →
Виталий Панасенко(дом)

  (2009-09-10 22:33)
[8]

намек: чтобы упорядочить, нужно активизировать индекс.. а чтобы его активизировать, его нужно построить. см.
> Anatoly Podgoretsky ©   (10.09.09 09:37) [2]
>
> То есть таблица без первичного ключа и каких либо индексов.
>

**High**. This error often corresponds to data lost in the MB file. Because this is usually only the BLOB data (the fixed data in the .DB is not affected), the results of the corruption may not be immediately apparent. Memo fields and image fields should be verified immediately. For orders, the description, production notes, and any images may be lost.

UPDATE "Order Details Database"
SET ModifierXML = ''
WHERE OrderDetailID > 0

Resolution 4 (Get assistance from a Tier 2 Tech)

01.01.2007

Объяснение от Борланд:

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 {Utilities, programs and updates section}.

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 {DbiOpenCfgInfoList } BDE API function call for more information.

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: {Q174371} and {Q165403}

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 {Q129202}

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. {The Delphi Magazine} has a number of interesting articles on this subject as well. See { www.itecuk.com/Delmag/Paradox.htm} for details. 

Примечание от Vit:

Обычно такие ошибки возникают из-за проблем с кэшированием измений в базе данных, особенно при использовании BLOB/Memo полей и особенно при многопользовательском доступе. В простейшем случае снизить частоту возникновения этой ошибки на несколько порядков помогает вызов метода FlushBuffers после каждого изменения таблицы:

Table1.post;

Table1.FlushBuffers;