Sounds like good advice, but I don't have any code that creates these DDL changes. Unless some 3rd party driver is doing this. I have written nearly every line of code in every app that is connecting to the database and I know that I am not creating a UTMP table or any other runtime DDL changes that would affect metadata. The only explanation might be that IBObjects or the .NET provider for Firebird is doing this that I used abundantly thourout my applications. I guess I will start digging into those. Thank you for the help. I will report any findings after my research.

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 04:49 AM 14/03/2009, you wrote:
> >I'm now loging all my db backup results with the -Y switch from my scheduler. I just ran it on all my databases. One is a DOCUMENT SERVER DATABASE all it has is three tables. I ran the scheduled backup procedure on it and got this result.
> >
> >gbak: ERROR:invalid request BLR at offset 13
> >gbak: ERROR: table id 171 is not defined
> >gbak: ERROR:gds_$compile_request failed
> >gbak:Exiting before completion due to errors
> >
> >I then ran a backup manually and it worked just fine no errors doing the backup. The manual backup was doing using IBConsole. The scheduled one was done using a windows service that shells out to windows to run the commands I sent earlier.
> >
> >What is going on??
>
> Do you have the sources to the user apps? Already from your various posts you've show several clues to help you find the offending code, viz.
>
> 1. Something is creating a table or called UTMP that contains at least one computed field and one index (which might be a PK or FK index).
> 2. Something (that table, or another arbitrarily created one) has a computed field referring to a table whose RDB$RELATION_ID IS 171.
> 3. Arbitrarily, instances of the app are creating, altering and dropping UTMP and maybe others.
>
> gbak -b comes in at noon and starts a transaction. Sometimes that table is visible in the system tables, sometimes not, and sometimes these arbitrarily created bits and pieces are part there and part not. gbak sees what's there at the split-second moment its transaction starts.
>
> So if you have apps running that are arbitrarily doing stuff that has committed unfinished DDL work that makes another transaction able to see stuff in the system tables that doesn't live there permanently, then queries by that transaction will retrieve output from the system tables that is unstable in unpredictable ways (I think you've shown us 4 possible ways, so far).
>
> Dig.
>
> All I can recommend is that you either *don't* schedule backups while anyone is potentially running this destabilising user code; or you fix it. You can replace it using GTTs (whose data is never seen by gbak) or, if the temporary sets need to be visible to other transactions/users for a while, by a persistent table into which the application writes its working sets with a set-specific identifier.
>
> ./hb
>