Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Dimitry Sibiryakov
28.01.2013 22:25, Helen Borrie wrote: > I think the jury is out on that theory. AFAIK, the 64K limit is on the size > of one SQL statement. A script is a lot of short SQL statements (on the > whole); although of course it can (and this one does) contain trigger and > procedure statements that

Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Helen Borrie
>28.01.2013 19:48, Helen Borrie wrote: >> A related issue: This particular database has a very large amount of >> metadata and the extract script was rejected by isql -input as being too >> large for its buffer. Do we know what the limit on isql's buffer size is? At 07:58 a.m. 29/01/2013, Dim

Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Dimitry Sibiryakov
28.01.2013 19:48, Helen Borrie wrote: > A related issue: This particular database has a very large amount of > metadata and the extract script was rejected by isql -input as being too > large for its buffer. Do we know what the limit on isql's buffer size is? If nothing changed since I saw

Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Helen Borrie
>>> gbak: ERROR:action cancelled by trigger (3) to preserve data integrity >>> gbak: ERROR:table/procedure has non-SQL security class defined >>> gbak:Exiting before completion due to errors >>> >>> What does the error signify? 28.01.2013 15:25, Alex Peshkoff wrote: >> Probably a bug. Can

Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Dmitry Yemanov
28.01.2013 15:25, Alex Peshkoff wrote: >> gbak: ERROR:action cancelled by trigger (3) to preserve data integrity >> gbak: ERROR:table/procedure has non-SQL security class defined >> gbak:Exiting before completion due to errors >> >> What does the error signify? > > Probably a bug. Can it be re

Re: [Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Alex Peshkoff
On 01/28/13 13:12, Helen Borrie wrote: > Backup of an ODS 11.2 database was made on a v.2.5 server using the gbak.exe > from v.2.0. The database structure doesn't use anything that v.2.0 doesn't > support and has no permissions depending on the RDB$ADMIN role. The backup > completed without an

[Firebird-devel] gbak: restoring privileges

2013-01-28 Thread Helen Borrie
Backup of an ODS 11.2 database was made on a v.2.5 server using the gbak.exe from v.2.0. The database structure doesn't use anything that v.2.0 doesn't support and has no permissions depending on the RDB$ADMIN role. The backup completed without any errors. During the restore on the v.2.0.7 se