--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> tractaylor wrote:
> > I was looking around the internet and trying to find a limit with

the

> > number of triggers a Firebird 1.0 database can have. I found

some docs

> > that referenced Ib 5.x and Ib 6.0, but nothing with Firebird

1.0. Is

> > the limit the same as Ib 6.0?
>
> The number of triggers per table didn't change. The number of

indexes

> per table did change in V1.0x from 64 to about 255 If I remember
> correctly. I've never heard of anyone running into a limit on the
> number of triggers on a table before. What are you doing?
>
>
> Regards,
>
>
> Ann

Hello Ann:

Remember this is with Firebird 1.0.

I am not really talking about limits per table, just limits in the
datbase because of page size. We do not have alot of indexes on
tables. I am guessing that the most indexes on one table is no more
than 7. We do have about 150 (guesstimate) tables though. Recently,
we added ALOT of triggers. User were requesting delete tracking on
tables. So we added triggers to log. I think this is causing the
problem.

But this is what lead me to the above.....


We have this client with a corrupt database. We found this because
when the client was trying to restore a backup, the server crashed.
To add, this client is a standalone workstation.


I have been trying to fix it with gfix -mend..... Well, this does not
seem to be working very well.

I found a while ago some instructions to fix a corrupt database.
Short version..I ran gfix -v -full, then gfix -mend -full -ignore....
(I am sure you have seen these instructions)

After I run the gfix -mend, it still shows some errors. Page errors.
So the instructions to fix a database say if you still have errors
run gbak. So I run gbak to backup the database. When trying to
restore this database (gfix -replace -v ), the server crashes, with
what looks to be when restoring indexes. I tried to get rid of the
index it was crashing on, but it then crashes on the next index in
line, so I did not think that was the solution.

So after fighting with this all day, I started thinking, it was
something that we did. That is what lead me to page sizes. After
reseaching a bit, I decided to try restoring the backup with the
following commmand "gbak -replace -p 8192 -v ". The outcome was
better, it did restore without crashing....

That is what prompted me to ask here. I think we made a huge screw
up, but I wanted a definate answer and not assume this.


I would also like to add Fb 1.5 restores it fine without changing the
page size. But I really wanted to find the problem before we decided
just to update this client. Currently, I don't want to have update
all of our clients (over 200) unless it is a must.

Thanks
Trac