SMTP Codeunit (400) locks file??

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.



Comment List
No Data
  • 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).

No Data