Today I've experienced something weird. Some weeks ago one of my customers did a technical upgrade from Navision 5 SP 1 to Navision 6 SP 1 (Aka NAV 2009 Classic Client SP1).
We decided to also move the Application Servers (Aka nassies) to a special server and to replace MiBuSo smtp with the newly introduced SMTP codeunit (400) in NAV 5 SP 1.
Now, this is a lot of changes... and off course something went wrong...
But this was not reported directly since the job that went wrong is still in development phase for end users to test. So after some weeks they said that a process was not running for a while. After investigation the error from the Job Queue was : You cannot use the file <<FILENAME>> because it is already in use.
This is where the reverse engineering process starts. What have we changed, did it ever work? With interfaces so much can go wrong.
I will not tell you the complete story, will be boring and take to long.
Short version: It seems that when you send a file with the SMTP codeunit (400) it will lock it, you cannot rename or delete the file. In this interface the filename needs to be exactly the same each time. This is why this interface fails and others like EDI and Order confirmations (without attachments) did not go wrong with the same SMTP function.
I am open for suggestions, meanwhile we moved this feature back to MiBuSo SMTP.
There is a KB fix from Microsoft available, see more here:https://mbs2.microsoft.com/Knowledgebase/KBDisplay.aspx?scid=kb$EN-US$2280492&wa=wsignin1.0
It occurs also when you use it with the client.
I created a small codeunit that emails a file. If you try to delete the file after it was sent it seems to be locked.
I would love to hear a bit more about this error. Is it only when you the scheduler and NAS or?
I have previously been using codeunit 400 and never had any problems.
Thanks. I tried that. I've tried everything I could possibly think of.
So my guess is that the good old Mibuso smtp is not .net right? Good old com/ocx.
It works for now. I don't like interfacing with other companies using e-mail with attachments anyway so hopefully we can move to something more fancy and reliable as webservices soon.
Last time we asked them about webservices they said sure, and told us the costs. Our guess was that we were the first to ask and pay the bill. This was over a year ago. We can ask again, maybe someone else has paid the development costs. (lol/cry dunno what to do).
It will be difficult to overcome this.
SMTP component it’s based on standard .NET class “SmtpMail”. This referred class is nothing more than a wrapper to “CDONTS.NewMail” automation. This automation locks file for modification on read, but this is the normal behavior for windows applications.
You might try to attach file and try immediately destroy automation using CLEAR, this way you will free file for modification.