A synonym belongs to its own schema, which is independent of the schema the DB object belongs to (of course, a synonym and its base object can have the same schema). Whenever you use a synonym, try to mentally replace it by its base object, that’s pretty much the same what the DB is doing. Synonyms are aliases for DB objects, but are no real DB objects by themselves (even though you can find them in view SYS.OBJECTS) . with some Admin-User: create user that PROVides the base object, and two CONSumer usersĬreate user SYN_PROV PASSWORD "Init1234" NO FORCE_FIRST_PASSWORD_CHANGE Ĭreate user SYN_CONS PASSWORD "Init1234" NO FORCE_FIRST_PASSWORD_CHANGE Ĭreate user SYN_CONS2 PASSWORD "Init1234" NO FORCE_FIRST_PASSWORD_CHANGE
The easiest way to do this is to open three SQL consoles, one for each user. That could be an end user, that is not allowed to access the replicated ERP Schema directlyįor simplicity reasons we will create three users and work directly with those users and their default schema, which has the same name as the user. When you read something like “–user SYN_PROV:” in the examples, this means, that the coding has to be executed by this user and the current schema is the default schema of the user. A third user (SYN_CONS2) shall only consume objects of the second user/schema, but never directly the objects of the first user.A second user (SYN_CONS) consumes the objects of the first User, directly or via synonym.This could be a schema we develop in, create DB views etc.
When I started to write a document on the usage of synonyms in XS Advanced, I noticed, that even though most people I talked to knew how synonyms work in principle, most people (including me) had their problems when it came to details. Whereas in classical SQL usage of synonyms is optional, in XS Advanced they will be the only way to access objects of a different schema.
0 kommentar(er)
