Hello, any suggestion on how to tame MsSql issues like this to make an
equivalent or mimic behavior on IB?

CREATE DEFAULT dbo.UW_ZeroDefault AS 0
go
IF OBJECT_ID('dbo.UW_ZeroDefault') IS NOT NULL
PRINT '<<< CREATED DEFAULT dbo.UW_ZeroDefault >>>'
ELSE
PRINT '<<< FAILED CREATING DEFAULT dbo.UW_ZeroDefault >>>'
go

The only thing is a domain, but an IB's domain is like an MsSql's User
Datatype. In this case, MsSql's defaults are only values. I read in the
online books:
«
Defaults, a backward compatibility feature, perform some of the same
functions as default definitions created using the DEFAULT keyword of ALTER
or CREATE TABLE statements.
»
So probably a default alone should be deprecated in favor of what MS calls
"default definitions" that are no more than the DEFAULT keyword inside a
CREATE TABLE command. In this regard, IB's domains provide both
functionalities: they are reusable across table definitions and they are
defined only one. This is the reason I think both User Defined Datatypes and
Default alones (made by CREATE DEFAULT) in MsSql should be mapped to IB
domains.

In that case, legacy crap like this:
EXEC sp_bindefault 'dbo.UW_ZeroDefault', 'Contacts.Custom3'
go
that usually appears AFTER the table definition would involve an immediate
ALTER TABLE to rebuild the affected field with the domain that implements
the default, unless a tool can look forward for these sp_bindefault in the
script before emiting CREATE TABLE statements for IB.

I will reiterate that MS considers defaults alone to be a backwards
compatibility (legacy) feature and they write about using default on every
field at table definition time, but they fail to tell that this can be done
by a Domain... well, User Defined Datatype for the non-ANSI MsSql.

Comments?

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com