Hi Stephen, [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote: > > Any progress on this topic? > Well, yes and no. I think I should explain a bit more in detail. The tool Loadercli is the completely 'dumb' client to the Loader server. This means it simply parses either the batch file or the interactive input for command separators (and it does not know anything else) and sends the input in between these separators to the server (in case server and client are linked together sending is simply passing as parameter). Well, and the command line options you give when calling the Loadercli define the first connect parameters. The Loadercli is (besides finding the command separators) able to build server connect commands (USE USER) using the given parameters and to send these commands to the server. In case the parameters are not complete the Loadercli does simply nothing - in your first case
> > > C:\>loadercli -n 192.168.0.150 > > > Loader Server Protocol File: 'c:\program > > > files\sdb\data\wrk\loader.prt' > > > > > > loadercli>USE USER test test SERVERDB TST > > > ERR -25004 > > > A connection to the database could not be established: 1 = > > > database not running. > > > the name of the database is missing to successfully connect and nothing is done. BUT as the client is not aware of the commands it is reading (it simply searches for separators) it does not recognize subsequent USE USER commands read in the batch file or from interactive input and thus can't complete the command with the server node name/address. The second example is simply an error. > > > C:\>loadercli -n 192.168.0.150 -d TST > > > Loader Server Protocol File: 'c:\program > > > files\sdb\data\wrk\loader.prt' > > > > > > Connection to database TST on 192.168.0.150 established. > > > loadercli>USE USER test test SERVERDB TST > > > ERR -25008 > > > Logon failure; previous user's () connection was restored. > > > Everything is given to connect to the db on the lowest level (to create a communication channel). And the Loader does connect as the message 'Connection to database ...' says. But at the first USE USER command the Loader 'forgets' the already known information and the connect fails. We'll correct this with one of the new version. As a workaround specify all connect parameters with the first USE USER command. So far so bad. > It is DBEXTRACT that concerns me most and is partly > responsible for misleading me :) DBEXTRACT creates a > catalog script that will do things such as: > > USE USER a > CREATE TABLE a1 > USE USER B > CREATE TABLE b1 > > instead of: > > CREATE TABLE a.a1 > CREATE TABLE b.b1 > Yes, and the Loader does right here. You can't create tables on somebody others behalf, can you? So you (the Loader) must simply log on as this user to create his/her tables. > But given that each of these "user user" defaults to > localhost, the script can only be run localhost without > manual revision to change > every "use user" to include the additional host parameters. > You shouldn't change those USE USER commands within the catalog script that you then run with CATALOGLOAD. These USE USER commands are slightly otherwise handled as 'normal' USE USER commands and a switch to another db or server wouldn't work here. And those USE USER commands do not necessarily default to 'localhost'. They depend on what USE USER command you run before CATALOGLOAD command. Suppose your localhost is server1 with db tst1 and you want to load the catalog to tst2 on server2. You run Loadercli on your server1 with the following commands: use user dba dba serverdb tst2 on server2 // catalogload all instream file '<ddl file>' All USE USER commands in <ddl file> would point to tst2 on server2 in this case. > When two servers are involved... and the database has tables > with different users... the problem shows quickly. > How can 2 servers be involved if you create the catalog or even (more than one) schemas in one db? Afaik we do not longer support distributed databasing. Could you give me an example what you mean here? Regards, Steffen -- Steffen Schildberg SAP DB Team SAP Labs Berlin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
