Possible intermittent problem ?

Dim strThisTime As String

strThisTime = Format(Now, "mm_dd_yyyy_____Hh_mm_ss")




Is there any possibility that strThisTime needs to be declared as a variant instead of a string ? Doesn't the use of Format() make it work ok ? When I say possibility, I mean it works 50 or 60 times, but on the 61st time the routine is called, the file name is bad ?


NOTE: strThisTime is used as a file name with & .txt appended as below.

Set txtfile = fso.CreateTextFile("C:\CES\XRF_Control\Data_Files\" & strThisTime & ".txt", True)


I'm getting an intermittent fatal error from the FSO. Error NO. -2147023446 ( Invalid code I believe )

The Format function returns a String, so strThisTime should be a String too.

I'm not sure the format you specified is safe, are the minutes actually correct? (the month might be used instead)


What is the value of strThisTime when the error occurs? Is there already a file with that name?

What is the actual error message?

Fatal Error writing data files !

Error Description = Method ' ~ ' of Object ' ~ ' failed.

Error Number = -2147023446

The subroutine is trying to write two files, one with a simple string name, the other with the Date/Time string name.

Here is the source:

Public Sub AutoWriteDispData()

Dim fso, txtfile
Dim ThisTime As Variant
Dim strThisTime As String

On Error GoTo FileError:

Set fso = CreateObject("Scripting.FilesystemObject")
' write file with time date stamp unique name
strThisTime = Format(Now, "mm_dd_yyyy_____Hh_mm_ss")
Set txtfile = fso.CreateTextFile("C:\CES\XRF_Control\Data_Files\" & strThisTime & ".txt", True)
txtfile.WriteLine (gblstrAcquisitionFileData)
txtfile.Close
Set fso = Nothing ' Free up resources

Set fso = CreateObject("Scripting.FilesystemObject")

' write file with time date stamp unique name
strThisTime = "SPC_Data"
Set txtfile = fso.CreateTextFile("C:\SPCData\" & strThisTime & ".txt", True)
txtfile.WriteLine (gblstrAcquisitionFileData)
txtfile.Close
Set fso = Nothing ' Free up resources

Exit Sub

FileError:
MsgBox " FATAL ERROR WRITING DATA FILES ! " & " Error Description = " & Err.Description & " Error Number = " & _
Err.Number
Err.Clear


End Sub

If you haven't done so already you could trap that particular error number and display or in some other way find out what the data is that you're trying to format. Also while I don't believe it would correct your problem, you should use Format$() for strings rather than Format().

Also, I should mention this same subroutine is exactly the same in two other units running just fine on two other machines. One machine has been writing these files for months with no problems....

That error message is a generic one, if you comment out the line On Error GoTo FileError: you might get a better one.


...and how about the answers to these questions?

Quote:

---

Originally Posted by si_the_geek

I'm not sure the format you specified is safe, are the minutes actually correct? (the month might be used instead)

What is the value of strThisTime when the error occurs? Is there already a file with that name?

---

Another suggestion would be to rewrite that sub without using fso.

I'm not sure the format you specified is safe, are the minutes actually correct? (the month might be used instead)

The file names seem ok, they reflect the actual date / and time down to the second when the file was written.



What is the value of strThisTime when the error occurs? Is there already a file with that name?

The first file written with the fixed name always exists. The second one of course doesn't due to the exact time being part of the name. The files are typically written once per hour.

Well in that case I've got no idea what the problem is... so I'd recommend Marty's suggestion of using an alternative to FSO, which could be like this:

Code:

---

Public Sub AutoWriteDispData()

Dim strThisTime As String
Dim intFileNum As Integer

On Error GoTo FileError:

  ' write file with time date stamp unique name
  strThisTime = Format(Now, "mm_dd_yyyy_____Hh_mm_ss")
 
  intFileNum = FreeFile
  Open "C:\CES\XRF_Control\Data_Files\" & strThisTime & ".txt" For Output As #intFileNum
  Print #intFileNum, gblstrAcquisitionFileData
  Close #intFileNum
 
  intFileNum = FreeFile
  Open "C:\SPCData\SPC_Data.txt" For Output As #intFileNum
  Print #intFileNum, gblstrAcquisitionFileData
  Close #intFileNum

Exit Sub
FileError:
MsgBox " FATAL ERROR WRITING DATA FILES !  " & " Error Description = " & Err.Description & "  Error Number = " & _
Err.Number
'(removed Err.Clear, as it doesn't do anything useful in cases like this)
Close #intFileNum 'this is safe in an error handler, as it will be ignored if the file number is not open

End Sub

---

Note that due to the keywords For Output the files will be replaced each time. If you want to add to the end of the SPC_Data file instead of replacing it, change For Output to For Append

Yes that's safe and as a matter of fact you can just say Close and all open files will be closed.

I definitely DO want to replace the fixed file name every time, another program reads it and the format is predetermined and cannot change.

I've kinda come to the same conclusion, since other units are working, this Host PC must have some problem that is preventing me from writing the files sometimes...

We will try a defrag and see if that helps.

It is highly doubtful that a defrag will have any effect, it is far more likely to be something like a security issue or the file being locked at the time - without a decent error message (which the non-FSO version should give you) you cannot tell what the problem is - and even if you manage to get the error to go away by trying various things, you can't be sure if that was due to what you did or just lucky timing.

Quote:

---

Originally Posted by MartinLiss

Yes that's safe and as a matter of fact you can just say Close and all open files will be closed.

---

True, but there may be files opened by other parts of the program, and they should probably not be closed due to an error in this routine.

I hear you, I've had this same conversation with management before. We are far past the point in our development where we find and fix errors daily.

The only Errors we see now are ones that happen like twice in a month. Very difficult to duplicate. And of course we never see them on the units here in the lab, only on units in the field 700+ miles away.

I thought the FSO was the best way to manipulate files, I guess this is not the case...?

FSO is designed for VBScript, and is just one of the methods that you can use in VB. As with any method, FSO has good points and bad points - the poor error message you are getting being a prime example.

Most people use the built-in methods instead (like I showed above). It is very rare to use FSO to actually read/write files, normally it is only used for things like creating folders and listing their contents, and moving/deleting files.

The way I see it, you can't fix the problem properly if you don't know what it is, so in this case at least FSO is not a good idea (because it isn't telling you the problem).

Well, as usual you guys have been a big help. Next version will have the new file writing methods...

BTW, another part of the program does write a file about 6-10 seconds later and it uses the other methods you guys recommended. It isn't having any problems...and it writes a file every time this routine does.

OH, well, live and learn...