At 08:29 AM 10/06/2009, you wrote:

>I upgraded fb 1.55 to FB 2.12 since a day and I've got this log:
>
>SERVER001 (Server) Tue Jun 09 17:51:58 2009
> Access violation.
> The code attempted to access a virtual
> address without privilege to do so.
> This exception will cause the Firebird server
> to terminate abnormally.
>
>Environnement:
>Windows 2003 Server R2 Standard Edition SP2
>Xeon 2.66 Ghz, 3.25 Go RAM
>Database 6 Go
>40 ~ 60 simultaneous Client/Server users

Are you telling us that you simply switched your live production system over from Fb 1.5.5 to Fb 2.1.2 without any mind to the changes in two full releases? Whatever else you do, don't delete your last good backup.

>I stopped fbserver process with procexp (sysinternals tool) after waiting a while and restarted it.

You crash-stopped a running server with 40 ~ 60 clients working? Why would you do that? You broke several indexes by interrupting writes.

>The validation reported this:
>
>SERVER001 (Server) Tue Jun 09 18:23:41 2009
> Database: D:\DATABASE\DATA001.GDB
> Index 3 is corrupt on page 330844 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1658
> in table DOC (203)
>
>
>SERVER001 (Server) Tue Jun 09 18:23:46 2009
> Database: D:\DATABASE\DATA001.GDB
> Index 10 is corrupt on page 345035 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1658
> in table DOC (203)
>
>
>SERVER001 (Server) Tue Jun 09 18:24:06 2009
> Database: D:\DATABASE\DATA001.GDB
> Index 1 has orphan child page at page 309549 in table HIS (239)
>
>
>SERVER001 (Server) Tue Jun 09 18:24:07 2009
> Database: D:\DATABASE\DATA001.GDB
> Index 2 is corrupt on page 350258 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1658
> in table HIS (239)
>
>
>SERVER001 (Server) Tue Jun 09 18:24:20 2009
> Database: D:\DATABASE\DATA001.GDB
> Index 8 is corrupt on page 350264 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1658
> in table HIS (239)
>
>
>SERVER001 (Client) Tue Jun 09 18:30:47 2009
> Guardian starting: "C:\Firebird\bin\fbserver.exe"
>
>Does a backup/restore will solve the indexes problem ?

Can't answer that. You will have to query RDB$INDICES and find out what this index is (RDB$RELATION_NAME = ? AND RDB$INDEX_ID = ? for the two tables in question). If they are constraint indexes, the repair work will be more complicated.

>is the "mini-crash" is due to fb2.12 migration ?

A migration, whether correct or not, doesn't cause an AV. In the normal run of things, an improper migration, at worst, causes exceptions.

An AV happens when code tries to refer to something that isn't available, either because it got dereferenced (e.g. through a bug or a race condition) or because it is locked by something that the database engine doesn't know about. The suspects here are Windows utilities, most likely its System Restore utility. Did you know that ".gdb" is a very dangerous suffix to use for databases on Windows Server 2003? System Restore actively targets files with that suffix and, when it is doing its "thing", it pre-emptively locks files whilst it copies the disk image. Some anti-virus applications present similar dangers to databases.

All the same, that is not to rule out some situation that was created by an improper migration, though. Having the wrong versions of the Microsoft VC8 runtimes could well break something by calling a function that doesn't exist. If you don't know what I'm talking about, then it's time you read the Installation and Migration notes.

./heLen