Greetings,
First of all, I believe that the dbid is only an issue when:
1. You have views, triggers and procedures and perhaps other new objects in other databases, refferencing objects in this database. In other words, for cross database dependencies...
2. As far as the mapping of disk space for a database on a device through sysusuages. e.g. there is a join between sysdatabases, sysusages, and sysdevices...
In any case, In all my years of working with Sybase ASE I have never heard of DBCC CHECKALLOC fixing this kind of issue. It is all a manual process, or, something you can automate in shell and T-SQL scripts.
So, the only way to copy a database from one server to another using backups e.g. dump at the source and load at the target, is to:
1. Create the database on the target server with the same dbid, and the same or very similar
mapping of sysdatabases, sysdevices, sysusages (the only way to really garantee a succedssful
load)
OR
2. Perform some manual reconciliation. The following like a clear and simple option:
In the source server, temporarily update sysdatabases.dbid and set it to the dbid of the
database you created at the target server. Dump the database, ftp the file, load at the target.
Voila!
If this is not possible, and to prevent any dbid clashes, create the database at the target server,
and bump up its dbid to a very large number not in use at the source or the target. Then bump the
dbid in similar fashion at the source, dump, ftp, load.
This will require updating the system tables in master on both servers:
exec sp_configure "allow udpates", 1
go
update master..sysdatabases.dbid = "Some large numberto beequal on both servers"
go
exec sp_configure "allow udpates", 0
go
I hope this helps.
Regards,
Jean-Pierre