Nahh sorry ... sure .. its having an running update-scripts on a versioned database .. the customer already having the latest version of the database.
The only other tool running such tasks is our repair-utility.

Well the log shows us its happending at 5am .. when the office is closed... there are no scheduled-tasks. most likely there were just the elevate-server and one of our client-apps running running some insert's .. as far as i know all commands are getting logged ..

at the moment we are checking if the server simply crash's .... or shuts-down for updates .. perhaps the automated-update-shutdown-stuff kill's the elevate-server in a bad way ... i will tell more if i know more

So Far Greetz

Michael

Are those the Windows logs you're checking or the Elevate logs? If the latter has anyone checked the Windows logs to see if there's a nasty event around the same time?

Are there any Windows tasks scheduled around that time - eg Windows update?

A simple insert into the database wouldn't stuff the catalog, but any change to the structure could especially if "Unexpected Networkerror."

Another thought - you say the logs say it happens about 5am - what's the timestamp on the .OLD?

Roy Lambert [Team Elevate]

We are currently waiting for the Windows-Server-Logs .. we think there is a problem too.
Well about to .old file i am pretty unsure ... i could swear the last time i seen the bug the .old file was 2 months old...
but my boss told my at phone that at the customer it's having the same timestamp ... ( dunno why ) ...

When exactly get these .old-files generated ?! on a "ALTER TABLE .." or on engine-version-updates?

Michael

>We are currently waiting for the Windows-Server-Logs .. we think there is a problem too.
>Well about to .old file i am pretty unsure ... i could swear the last time i seen the bug the .old file was 2 months old...
>but my boss told my at phone that at the customer it's having the same timestamp ... ( dunno why ) ...
>
>When exactly get these .old-files generated ?! on a "ALTER TABLE .." or on engine-version-updates?

The best way to think of the .OLD files is as an automated backup. For the data files its when you alter the table structure, or do a repair, for the catalog its (I think) any of the events that can alter the catalog eg creating tables, functions, procedures etc or altering them.

Roy Lambert [Team Elevate]

Adam,

<< I think I might agree with Roys speculation. If somewhere you have a
program on a dramatically different build of EDB it could be messing with
structures in this way. I know there can be problems with BLOB field-storage
between different builds. >>

I think you're thinking of DBISAM 4.28 vs. 4.27 and earlier.  EDB doesn't
have any issues with BLOB storage between versions/builds.

Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< .. and again .. the catalog file is damaged. this time we used the
precompiled elevate-server-binary. So i think the Version is not problem
anymore cause all our client-apps are using the server-process. >>

Did you confirm whether there is AV software running on the server machine ?
Something weird is going on that is causing this, and I doubt very much if
it's EDB.

Also, to answer the other question posed: no, EDB won't write out a catalog
file full of zeros.  The files are only written as much to handle the data
in the catalog, and that's it.

In addition:

1) The .old file is created via a catalog write *immediately before* the
actual catalog is written to.  Therefore, EDB would have to be encountering
a situation where it can write out the .old file, but fails on writing out
the actual catalog file.

2) There is an exception-handling block around all catalog updates that will
automatically restore the .old file contents back into the actual catalog
file, and then deletes the .old copy.  If the .old copy exists, then this
exception block did not get triggered.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Hi @ll,

got some updates .. we have 2 more customers having that issue ..
they all share are using server-locations for the database.
It looks like only happens in network-enviroments ?!

I triggered that a other worker created a temporary-table on the application-startup that causes the creation of the .old file ... i think that is the point where for some strange reason the EDBCat just only get the header filled...

Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15

00000000   16 44 82 08 96 30 83 54  38 65 45 75 3E 5E DB 80    D‚ –0ƒT8eEu>^Û€
00000016   00 00 00 00 00 CE 85 01  AA C5 39 B4 BD 4C 54 32        Î… ªÅ9´½LT2
00000032   7E 41 D9 75 B0 20 07 00  00 00 00 00 00 A0 60 03   ~AÙu°         `
00000048   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000064   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000080   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
.... the old file is a few seconds aged but looks that way ...

Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15

00000000   16 44 82 08 96 30 83 54  38 65 45 75 3E 5E DB 80    D‚ –0ƒT8eEu>^Û€
00000016   00 00 00 00 00 CE 85 01  AA C5 39 B4 BD 4C 54 32        Î… ªÅ9´½LT2
00000032   7E 41 D9 75 B0 20 07 00  00 00 00 00 00 A0 60 03   ~AÙu°         `
00000048   00 00 00 00 00 00 00 00  14 50 00 00 00 00 00 00            P      
00000064   25 41 00 00 01 00 00 00  04 00 00 00 07 00 00 00   %A              
00000080   44 65 66 61 75 6C 74 0E  00 00 00 44 65 66 61 75   Default    Defau
00000096   6C 74 20 53 63 68 65 6D  61 00 00 00 00 00 00 06   lt Schema       
00000112   00 00 00 53 79 73 74 65  6D 00 00 00 00 2A 00 00      System    *  
00000128   00 66 00 00 00 0A 00 00  00 41 64 64 72 4F 66 66    f       AddrOff
00000144   69 63 65 0E 00 00 00 42  FC 72 6F 20 41 6E 73 63   ice    Büro Ansc

okay .. well why is the header filled but not the rest !?! ...

nah .. i think we will stop using temporary-tables where possible .. this should reduce the problem ..

so far ...

Michael


Have you tried just creating and dropping a temporary table using EDBManager? I just did and no .OLD file created.

Also from Tim's post

<<Also, to answer the other question posed: no, EDB won't write out a catalog
file full of zeros.  The files are only written as much to handle the data
in the catalog, and that's it.>>

There HAS to be something else involved.

Roy Lambert [Team Elevate]

You're right .. its not the create temporary table .. it is the create index on the temporary table.

Well thats quite strange .. if you write-out the cat.-file at once there is no reason why it should be zero-filled except:
- The File cannot be saved correctly. (Atleast one customer is having a Network issue)
- The File is already corrupted in memory. (But that should raise some kind of out of resource exception) ..
.. mhm yesterday a customer had the error while working .. the create index is just used once while the application starts... thats all quite confusing.