Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Tcl Library › TCL proc issue with Mapped drive
- This topic has 12 replies, 6 voices, and was last updated 14 years, 8 months ago by David Barr.
-
CreatorTopic
-
October 15, 2009 at 6:55 pm #51253Brian SweetlandParticipant
I -
CreatorTopic
-
AuthorReplies
-
-
October 16, 2009 at 1:55 pm #69388Russ RossParticipant
Just curious if you create a short cut on C: called C:R_Drive such that when you open C:R_Drive in windows explorere it takes you there, then you reference C:R_Drive in your TCL code instead of R: and see if that works.
Granted it will not tell you why R: is not working but could be a work around.
I found this shortcut method useful when using windows exploere since our mapped drives disappear sometimes and I have to recreate them but this way I have a shortcut that documents where the heck they are even when the mapping disappears.
Yes they show in the map drive drop down but with so many of them and no drive letter relations it was not easy for me to connect the dots but now it is.
Russ Ross
RussRoss318@gmail.com -
October 16, 2009 at 4:31 pm #69389Brian SweetlandParticipant
Short cut doesn’t seem to work. I can’t figure out how to identify it in the TCL code.
Example, I create a short cut of my “R:” drive called “rDrive” and place it on C:. When I run;
file exists “C:\rDrive”
I get “0”.
The other thing I tried today was calling a Command file from my TCL proc that runs in QDX.
exec cmd /C “mypath\mycommandfile” > null
It works fine in HCITCL, but if I try to run this in the TCL proc in QDX, I get “No default site — no site set”
-
October 16, 2009 at 8:21 pm #69390Michael HertelParticipant
Do you run as the same user with the same permissions or is the engine running as hciuser and you are running as your own login id?
-
October 16, 2009 at 10:45 pm #69391Brian SweetlandParticipant
Different.
The QDX runs as HCIUSER. The system user is different. We had the customer set up the share with the system rights.
One of my coworkers was telling me how he used the QDX protocol “Mapped Drive” to connect to a shared drive, but in order to get that to work he had to have the site set up the share as the HCIUSER and add the domain. I was hoping that the TCL proc would avoid this. My experience has been difficult asking Customers to add our user and domain to thier network. And if they do, it seems to get dropped somewhere along the line.
I’m thinking of 2 options now. 1-have the site setup the share as FTP, then I can user QDX to send my PDF files through the engine.
2-set up a scheduled task every 5 minutes to call a Batch file that copies from my local directory to the shared directory.
-
October 23, 2009 at 4:14 pm #69392Brian SweetlandParticipant
Okay, I have one even stranger.
I can
-
October 26, 2009 at 3:35 pm #69393Russ RossParticipant
I might be in outter space but I’m going to think out loud a bit.
There is a voice inside my head that is saying to try and do a ls (directory listing) of the mapped drive directory in your TCL code before your copy command.
I can’t connect the dots in my mind but that popped into my head as a possible work around to a mapped drive issue.
Russ Ross
RussRoss318@gmail.com -
January 15, 2010 at 4:21 pm #69394Jennifer HardestyParticipant
Did you ever resolve this? I seem to be having a similar issue trying to copy a file from an ftp folder to Cloverleaf. Cloverleaf processes the messages in the file, but when I try to copy the file, I get a message that says there is no file.
-
January 17, 2010 at 1:19 pm #69395Brian SweetlandParticipant
I did not resolve this the way I had hoped. I ended up doing all of my TCL file renaming and moved my local files to a TEMP folder. I then setup a scheduled task (batch file) to run every 15 minutes to copy/delete my files from the TEMP folder over to the Mapped drive.
Not really what I wanted. I wanted my file copy to be done in the TCL proc in real time and avoid the scheduled task.
-
January 19, 2010 at 4:34 pm #69396Levy LazarreParticipant
Brian,
A while ago, I was trying to do something similar (moving a pdf file) and I also found that Tcl would not let me use a mapped drive.
The work around was to create a share on the Windows server and set the appropriate permissions on the share. Tcl was then able to access the share and write the pdf file using the syntax
//servername//sharename/pdfname (with forward slashes)
or the longer form with backslashes
\\servername\sharename\pdfname
Have you tried using a server share instead of a mapped drive? The share worked for me.
-
January 19, 2010 at 8:55 pm #69397David BarrParticipant
I’m not quite sure why you were trying to use a TCL “file rename” command to move the file instead of forwarding it as a message to a fileset-local thread, but if you’ve got something working now, it probably not worth it to go back and fix what isn’t broken.
-
January 20, 2010 at 1:32 pm #69398Brian SweetlandParticipant
I receive an XML msg via TCP to my thread. I then parse that msg to get needed info to go and find a corresponding PDF file in a different local folder. Then I take key info from that xml msg (MRN, acct#, etc
-
January 20, 2010 at 6:27 pm #69399David BarrParticipantBrian Sweetland wrote:
The PDF file never actually goes through my thread. Only the xml msg.
I then need to move that PDF to a customer server.
Right. I was suggesting that you could either create a new message or replace the existing XML message with the contents of the PDF, and route the new message to a thread that delivers directly to the customer server. You could use the identifiers from the original XML to update the driverctl metadata so that it would be delivered with the correct filename. If the customer server is accessed through a mapped drive, the thread protocol would be fileset-local.
-
-
AuthorReplies
- The forum ‘Tcl Library’ is closed to new topics and replies.