This content has been marked as final. Show 5 replies
Where do you see that the docs say the same thing (about not setting the variable)?
I see on page 5, under Database Configuration, of the Sybase install guide:
"Set the DSQUERY variable to the server that contains the database that Oracle GoldenGate will be using."
Thanks, I did see that, which is why I tried it.
I was looking at...
Reference Guide, Page 381-384, USERID, Example 3.
It doesn't explicitly say which platforms the syntax works for.
If I must set DSQUERY, how do I write to multiple targets from a single server?
Well, using that example, it assumes the connection knows where to go, either as a result of the connection string, or an environment variable.1 person found this helpful
If ORACLE_SID were set, then:
userid whomever, password whatever
...works. If not set, then:
userid whomever@SID, password whatever
...works. What is the corresponding connection string for Sybase?
isql -U<username> -P<password> -S<server name>
Does Sybase login in support username@<server name>, password whatever? I don't think so (Sybase isn't my thing), so using DSQUERY is how GoldenGate translates the @whatever part of a connection string. Ergo, DSQUERY is set.
You could also try using SETENV in the parameter file and then default to userid xxx, password yyy.
DSQUERY refers to an entry in the sql.ini (windows) or interfaces file (nix). It is very much like tnsnames.ora (to the best of my knowledge).
Your isql syntax is correct. You can either set DSQUERY or use the -S flag. Either way, the server must be in sql.ini (I haven't used an LDAP solution). That's where it resolves the host name and port, etc.
"Does Sybase login in support username@<server name>, password whatever?"
That's all very dependent on the application/language, isn't it? Isn't really "How does GoldenGate form Sybase connection strings based on USERID and/or DSQUERY?". But you're right, the question really is how do we properly fill in the connection information.
Thanks for the tip on SETENV. So far that is working in my current scenario. It doesn't work for DBLOGIN since it needs to be in a parameter file, however that's not a big deal. Getting the replicats connected is!
Thanks for your help! It's much appreciated.
"you can also include the source DB server in the dblogin command shown as follows:
dblogin sourcedb sydatabase@ASE1 userid ogguser password ogguser"
in your case it must be
dblogin sourcedb db01@syb000, userid myuser