0000947: Firebird 3.0 support - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000947	Database Comparer VCL	General	public	2016-05-03 00:49	2019-04-18 19:43

Reporter	shirokov	Assigned To	barry
Priority	urgent	Severity	feature	Reproducibility	always
Status	closed	Resolution	fixed
Fixed in Version	7.0.0.1680

Summary	0000947: Firebird 3.0 support
Description	One of the customers wrote: Database comparer issues and bugs: master FB2.5 database backup and restore to FB3.0 and target and old metadata database same restored on FB3.0: 1- table column type or domain cannot be changed, as long as it update this in system table: Rdb$relation_Fields.Rdb $Field_Source 2- I don’t understand when compare and update attept to change column's domain, why it clean default to one table column in target, even if it have same default in master database, as long as old/target domain don’t have default but new domain (master) have it.. Anyway, doesn't matter how is set the default for that column in old (in target) domain or new(in master), as long it have default as column in both: old database (target) and new database (master), why Database Comparer clear it's default in target? because it have default also in new domain of some if are wrong there. Another bug, it's REVERSE: It remains so and all compares after didn't see it as difference. !!! But if I put default in old database/target, it keep it, as long as domain don't differ already. So: it looses default on column when changes made as it's domain, but also it didn't see it as difference. 3- it looses default to procedure's columns which differ as char case(lowercase) in many ways: for example in default on a column, example: null, or in comments or in code, even if in that code which IbExpert makes it automatically: create or alter procedure ...<parameter> timestamp/char/..etc. .. returns.. as declare variable.... begin... <here are uppercase from us> end, but this seems hasn't work in v.6.0.0.1641, and solved in the meanwhile, but I'm not so sure. - there are both cases, -- most often continuously se them as they differ procedures with default values on parameters in both database; making us delete their default values, -- and REVERSE case I had touch when I changed them until don't see they differ but because lost default value in target but not in master, that's mean they really differ but it didn't see them differ. - lately I observed by that default make them seen as differ all time, even if they don't by differ really by anything. 2&3: I think it looses defaults on procedure's parameters/columns or table's columns by same reason (we didn't used defaults on table's columns until now over domain's default neither in procedure's columns not so important to us, that we didn't saw those until now). 4- field character set and collation doesn't work, cannot be changed in system tables, neither with alter. - charset differences don't work as long as they're update in RDB$RELATIONS.RDB$CHARACTER_SET_ID - collate for columns which made directly with type char/varchar, without domain, which are automatically COLLATE UNICODE_FSS, they are continuously differ and also don't work as long they're UPDATE in RDB#RELATION_FIELDS.RDB $COLLATION_ID, but I don't find DDL statement for change collation of a column 5- it losses also not null in procedure's parameters/columns which differs also in case. 6- So, my metadata compares shows it looses comments(also in view-s), not null in procedure's parameters/columns, and table's column's default, if you want I can give you both metadata. - procedures with same comments not between begin and it’s main statement, but after as or declare variable or variable commented or at end of views make them see as differ continuously. - and REVERSE issue, I had touch one time oposite situation: procedures had lost their comments and not had seen as diference. This may be Firebird3.0 issue and maybe can't be solved from DataBase Comparer. 7- this only to be checked, because I thing was a problem in our designing database in BRL differ from system tables: - it do a grant for an object to sysdba in target for sysdba if in master have another owner, even if they don't differs: they have grants in both databases (master and target) for both users(sysdba and that owner in master). - also this can be from our design database BRL: also don't see all grants for users to procedures also of users for roles, etc. And others see them continuously even if update: Here I admit I don't know what happens because I don't see them either in metadata extracted, but they are still in grants and in system tables. I don’t know why metadata don’t see them. ------this was done. hasn't work in v.6.0.0.1641, only to be checked again: ------comments extracted with IB/FB: Update Description using: COMMENT statement(Firebird 2.x) even if in SQL are COMMENT ON statements is ' ' it act as editing in system table RDB$Relation_Fiends, only in Execute Script (F9), but not in Update Script page: Execute Statement(F8), one by one, which solve problem definitively.
Tags	No tags attached.

Date Modified	Username	Field	Change
2016-05-03 00:49	shirokov	New Issue
2019-04-18 12:08	barry	Assigned To	=> barry
2019-04-18 12:08	barry	Status	new => resolved
2019-04-18 12:08	barry	Resolution	open => fixed
2019-04-18 12:08	barry	Fixed in Version	=> 7.0.0.1680
2019-04-18 12:08	barry	Note Added: 0004071
2019-04-18 19:43	barry	Status	resolved => closed