Classic ASP CDO sendmail

[#1]

i've got a script where a use fills out a form and attaches a document.
the document gets uploaded to another internal sever (not the webserver), and then an email is sent to the use informing that it has been submitted etc etc.

what i am trying to do now is attached that uploaded file to the resulting email.
the webserver has access to the folder on the other server where the file is uploaded to.

the file is uploaded to \\servername\subfolder\filename.ext

the part i can't seem to get to work is the myMail.AddAttachment part
i already have the full path of the file set as a variable in the script (in this instance called "doctest".

	Set myMail=CreateObject("CDO.Message")
	myMail.Subject="subject"
	myMail.AddAttachment Server.MapPath(doctest) 
	myMail.To="test@test.com"
	myMail.TextBody=emailcontent

I get this error when trying this

Server.MapPath() error 'ASP 0174 : 80004005'
Invalid Path Character(s)
test.asp, line 77
An invalid '/' or '\' was found in the Path parameter for the MapPath method.

anyone any ideas if this should work?

[#2]

It's been quite some time since I worked with Classic ASP, so maybe mis-remembering here.  Doesn't Server.MapPath() give the full path from the relative path that you pass in as a parameter?

Since doctest is the full path to the file wouldn't it just be that which is assigned to the myMail,AddAttachment?

ie

myMail.AddAttachment doctest

Edit: Corrected code.  I had a comma in where a full stop should have been. 

[#3]

i will give that a try, wasn't something that i had considered.

[#4]

that didn't work sadly.

Object doesn't support this property or method: 'myMail.AddAttachment'

this is my test script

<%
uploadedFilePath = "\\server\data\2503_2017071192320_test.pdf"

Set myMail=CreateObject("CDO.Message")
myMail.Subject="TEST"
myMail.To="test@test.com"
myMail.HTMLBody = "<h1>This is a message.</h1>"
myMail.AddAttachment = uploadedFilePath
myMail.From="test@test.com"
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver")="mailserver.com"
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserverport")=25
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing")=2
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate") = 0
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpusessl") = False
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpconnectiontimeout") = 20
myMail.Configuration.Fields.Update
myMail.Send
set myMail=nothing
%>

[#5]

Why not just keep a copy of the file on the Web server and attach that, send then delete it?

File paths and shares can be a pain when on other machines in any language. Also if your file storage server is turned off or rebooted when a user has submitted a file then your script can cache the uploads until that machine is seen online again via ping etc.

[#6]

the file never exists on the webserver.
the user fills out the upload form, and it saves it direct to the final location.
the fact that it can upload to the final location means there is no problem with communication between the web and file server.

the file server is never turned off, it's a 24/7 operational system!

[#7]

Yes I'm aware of that but what I'm saying is why don't you change that? The file is sent via http to the Web server where the form handling code saves it to the other machine right? So adjust the form handling code to save it to both machines.

I don't doubt both machines can communicate but it looks to me like a permissions problem or something with your language that is being problematic. What happens if your second machine develops a fault like a psu failure? - although rare, these things do happen. That's why I would save the file locally first, attach to email and send and THEN move it over to the other machine and delete the local copy. That way you have some protection if the other machine drops off the radar for any reason and it should simplify attaching your file too.

[#8]

if the second machine develops a fault then the business ceases operating, and the ability to upload a file via a webserver becomes a moot point.
we are not talking about a PC in a corner running as a server here, we are talking corporate level business servers in a managed environment.

i know it's defintely not a permissions issue, so that can be ruled out.
it may be a code issue, and that's what i want to focus on in trying to resolve.

[#9]

@chenks76 - Have you tried:

myMail.AddAttachment(uploadedFilePath, username, password)

Where username / password are those needed to access the remote share.

[#10]

a user/pass is not required at this stage, as the ISS server has the required permissions set already to allow communications between servers. this is what allows the upload to take place initially.

[#11 · Accepted solution]

OK then try :

myMail.AddAttachment(uploadedFilePath)

[#12]

hurrah! that worked!
probably the only combination that i never initially tried.

[#13]

So as you know why that works it is because .AddAttachment is a function, not a property. This function takes parameters, some optional;  resource, username, password for example. However what you were trying to do is assign a value to the .AddAttachment function which of course was failing.

[#14]

---

@chenks76 wrote:
if the second machine develops a fault then the business ceases operating, and the ability to upload a file via a webserver becomes a moot point.
we are not talking about a PC in a corner running as a server here, we are talking corporate level business servers in a managed environment.

i know it's defintely not a permissions issue, so that can be ruled out.
it may be a code issue, and that's what i want to focus on in trying to resolve.

---

Even so surely the secondary system going belly up would make the primary server experience slightly borked?

As for a PC in the corner of the basement.. those are your words not mine. I never assumed anything like that. These days far too many people / organisations have access to hi end stuff and low end prices thanks to ebay etc.

Anyway good to hear that you got your problem resolved.

[#15]

you have it round the wrong way.
the webserver is the secondary system, and the file server is the primery server.
if the primary server is down then the secondary server, by default, is also down.

we have the usual enterprise grade UPS's installed and a backup diesel generator should there ever be a power outage.

should the hardware fail in the primary server then we have fail over, via fibre link, to a remote site that has a mirror copy of the primary server.

you created a problem that doesn't exist. the problem WAS code and was easily solved.