Damn, if I'd need to recreate most of my primary keys, that is going to be a
major pain... I found a query to activate all indices but isn't there a way to
deactivate them all in the right order to achieve the right effect?
22.08.2015 16:06, tvd...@ymail.com wrote:
Rebuilding the indices is not the issue. It's just that the warning
implies that rebuilding the whole database is really better than just
rebuilding the indices. Am I still at any kind of risk if I just rebuild
the indices? What is the worst thing
Den 22.08.2015 15:26, skrev Dmitry Yemanov dim...@users.sourceforge.net
[firebird-support]:
22.08.2015 16:06, tvd...@ymail.com wrote:
Rebuilding the indices is not the issue. It's just that the warning
implies that rebuilding the whole database is really better than just
rebuilding the
Alright, so the remaining questions to someone with that knowledge are:
- Does the problem going from 2.5.1 to 2.5.4 still only concern compound
indices containing at least one NULLable (VAR)CHAR and no other indices than
that?
If not, what else?
- Is the following code enough to rebuild a
That's very interesting! Does this behavior still exist? Is there any way to
verify that?
So basically, if I execute the following after moving from 2.5.1 to 2.5.4 I
should be fine?
SET TERM !! ;
EXECUTE BLOCK AS
DECLARE VARIABLE stmt VARCHAR(1000);
BEGIN
for select 'ALTER INDEX
All those constraints are a dependency hell. Are there any significant
downsides to just using 2.5.2 for a year with the 2.5.1 database, considering
2.5.1 was working fine for me, and all I need more is the additional
service_mgr functionality of making remote backups? Then in a year I can do a
I thought 2.5.2 behaves the same as 2.5.1 but now I'm running into sources that
say that even 2.5.2 requires action when coming from a 2.5.1 database.
Is the old info still actual that I only need those constraints that are both
compound and have at least one (VAR)CHAR in them without 'NOT
