Sybase strongly recommends that you create users, domains and messages on the write server only; otherwise static collisions could lead to unintended results.
User names on the write server are global. For example, suppose that the DBA creates a user name chris for user Christopher Jones that exists on a query server only and owns objects on that query server.
Subsequently, the user chris is created for user Christine Smith on the write server. Now there is only one user chris, who is Christine Smith, and Christine Smith now owns objects on the query server formally owned by Christopher Jones.
A similar problem exists for domains and messages because both have a flat global namespace. Even though they are owned by a user, there is no way to qualify the name with the owner name.
After a static collision, the original query server message or domain is renamed. However, any query server object that references the original query server message will now reference the new message. A query server object that references the original query server domain will either reference the original or the new domain, depending on whether it references it in a definition (e.g. a table) or dynamically (e.g. in a stored procedure).
Sometimes it may be best to set permissions differently on query servers. Consider these factors:
Synchronizing copies user and permission definitions from the write server. The stored procedure sp_mpxcfg_servername (where servername is the query server name) may be used to reset the query server values to the desired state as part of the synchronize. If the query server has an IQ Local Store, the user privileges will be re-established as part of the synchronize. You can use the -iqlocalreplay server switch to override this.
In the event of a disaster, the Catalog Store of a query server may be used to recreate the write server. In that case, differences on the query server leave the new write server in a different state from before the disaster.
Setting permission on the query server is not permanent. The query server will continue to see GRANT and REVOKE commands from the write server. If the write server resets the permission, the change propagates to the query server.
