Drive mapping for text files and odbc

wdudek · Post by **wdudek** » Wed Nov 10, 2004 1:19 pm

I'm trying to get an odbc connection for fox pro to work on our datastage server (win 2000), the drive is mapped using net use to another server in an nt domain, although all of the servers use novell as well, I can open it up and look at it without a problem through windows explorer, and using access I can even open the tables. Using Designer, I cannot open these odbc connections, so I decided to try accessing a file on the server and noticed that the mapped drive is not showing. Instead I am seeing only the drives that are mapped through the Novell login script, and nothing mapped after the fact through Windows. So I believe that this is where my odbc problem lies, and that understanding where the available drives for datastage come from may help my odbc problem. I have tried running the datastage service as both administrator on the datastage server as well as the domain administrator and have not been able to view the drives either way.

Does anyone know where datastage is getting the available drive info from?

Thanks in advance for any light anyone can shed on this.
Bill

ray.wurlod · Post by **ray.wurlod** » Wed Nov 10, 2004 2:16 pm

Can you see the mapped drives when you try to import a table definition?

Is your ALLOWNFS configuration value set to 1?

wdudek · Post by **wdudek** » Wed Nov 10, 2004 2:47 pm

I tried importing a table definition for a text file on one of the mapped drives, but the drives do not show up there either. Also the ALLOWNFS parameter is set to 1.

Any other thoughts on the matter would be great.

Thanks,

wdudek · Post by **wdudek** » Mon Nov 15, 2004 4:44 pm

I called Ascential support on this, and was able to get from them that my problem is due to the security implementation in our network. When I log into thorugh the client, a security token is created and passed to the server. When I try and login to the other computers through mapped drives, odbc, etc. this token is copied and that is where the problem lies. The copy of the token is not valid in our network. Apparently is we were using windows kerebos security, this would be acceptable.

Ascential was able to point out to me that the jobs will run correctly if they are scheduled, so what I have doen is to use local copies of the data for development and then switch to the production versions for production. This works ok, except that I cannot truly run the job adhoc, instead if it needs to be run any time other than the standard scheduling dictates I need to schedule it to run once a couple of minutes after the current time.

Thanks,
Bill