|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
VB 6, SP 5 and HyperthreadHelp! I have a customer with a semi custom application written in VB6, sp5. The program mainly writes text files to disk from things organized on the screen. His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, 512 MB ECC memory, and Hyperthread enabled. He is running XP-Pro, sp2. Problem: Typically, the text files randomly get extra blank lines added to them. Rarely, a few of the text lines get truncated. And, even more rarely, whole line will go missing. So, the author switched from VB's built in text file writing code to WinAPI's Write File. Yippee!! Now the text file only gets the occasional random blank line added. Here is the rub: turning off the Hyperthread in BIOS fixes the problem! (Editorial comment: AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) Is there some problem with VB6, Sp5 and Hyperthread? And, is there a way to fix it? Compile it with some Hyperthread libraries? All suggestions welcome! Many thanks, --Tony
Show quote
Hide quote
"Tony" <T***@invalid.com> wrote in message My guess the box is over-clocked.news:dip440$ijj$1@domitilla.aioe.org... > Hi All, > > Help! > > I have a customer with a semi custom application > written in VB6, sp5. The program mainly writes text > files to disk from things organized on the screen. > His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > 512 MB ECC memory, and Hyperthread enabled. He > is running XP-Pro, sp2. > > Problem: Typically, the text files randomly get extra > blank lines added to them. Rarely, a few of the text > lines get truncated. And, even more rarely, whole > line will go missing. > > So, the author switched from VB's built in text > file writing code to WinAPI's Write File. Yippee!! > Now the text file only gets the occasional > random blank line added. > > Here is the rub: turning off the Hyperthread > in BIOS fixes the problem! (Editorial comment: > AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > > Is there some problem with VB6, Sp5 and Hyperthread? > And, is there a way to fix it? Compile it with some > Hyperthread libraries? All suggestions welcome! > > Many thanks, > --Tony -ralph Ralph wrote:
>> Is there some problem with VB6, Sp5 and Hyperthread? I built it. It isn't.>>And, is there a way to fix it? Compile it with some >>Hyperthread libraries? All suggestions welcome! >> >>Many thanks, >>--Tony > > > My guess the box is over-clocked. > > -ralph > "Tony" <T***@invalid.com> wrote in message The only thing I could find in the KB was the article below, which I doubt news:dip440$ijj$1@domitilla.aioe.org... > > Is there some problem with VB6, Sp5 and Hyperthread? > And, is there a way to fix it? Compile it with some > Hyperthread libraries? All suggestions welcome! > > Many thanks, > --Tony will help. Cannot Run Certain Programs on Hyper-Threaded or Dual-Processor Computers with a CPU Speed of Greater Than 2 GHz http://support.microsoft.com/default.aspx?scid=kb;en-us;327809 If there were "Hyperthread libraries", you'd probably need to get them from Intel, since they're the only ones that support that mess. Note that, if your customer was running a Dell (at least, all Dells I've seen), they wouldn't have been able to disable Hyperthreading because Dell doesn't think its customers are smart enough to have the option. Puke on Dell <g> I run AMD-64's so there's no funky/false 2nd CPU -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups.. Ken Halter wrote:
> Dell does not want you fooling with the bios. I prefer Supermicro> Note that, if your customer was running a Dell (at least, all Dells I've > seen), they wouldn't have been able to disable Hyperthreading because Dell > doesn't think its customers are smart enough to have the option. motherboards with generic bios. > So, the author switched from VB's built in text This to me sounds like 2 processes try to append to the same file, but may > file writing code to WinAPI's Write File. Yippee!! > Now the text file only gets the occasional > random blank line added. not be the case with your situation. If so, you have to do the following: 1 - Lock the file. 2 - Move the file pointer to the end of the file. Your process does not get notified if another process added to the file, so the file pointer is not moved in your process. 3 - Append the text. 4 - Unlock the file. Here is an example I posted in another thread: Option Explicit Private Sub Form_Load() ' How to use AppendLine "C:\Hello.txt", "Test1" AppendLine "C:\Hello.txt", "Test2" End Sub Private Sub AppendLine(ByRef FileName As String, ByRef LineToAdd As String) On Error Resume Next Dim f1 As Integer Dim i As Long Dim Locked As Boolean f1 = FreeFile Open FileName For Append Access Read Write Shared As #f1 If Err.Number <> 0 Then MsgBox "AppendLine: Cannot Open/Create " & FileName & vbCrLf & "Error " & Err.Number & ": " & Err.Description Err.Clear Exit Sub End If ' Retry locking the file; up to 100 times Locked = False For i = 1 To 100 Lock #f1 ' Lock the entire file If Err.Number <> 0 Then ' Lock failed Debug.Print "AppendLine: Lock retry "; i; " failed." Err.Clear ' Wait 0.05 second before trying again Delay 0.05 Else ' Successfully locked Locked = True Exit For End If Next On Error GoTo 0 If Locked Then Seek #f1, LOF(f1) + 1 ' Write the line Print #f1, LineToAdd ' Use "Print #f1, LineToAdd;" if you don't want a new line at the end Unlock #f1 Else ' All retries failed to lock the file MsgBox "AppendLine: Cannot lock file." End If Close f1 End Sub Private Sub Delay(ByVal Seconds As Single) Dim t As Single t = Timer Do While Timer - t < Seconds If t > Timer Then ' Adjust for midnight rollover to 0 t = t - 86400 End If Loop End Sub Show quoteHide quote "Tony" <T***@invalid.com> wrote in message news:dip440$ijj$1@domitilla.aioe.org... > Hi All, > > Help! > > I have a customer with a semi custom application > written in VB6, sp5. The program mainly writes text > files to disk from things organized on the screen. > His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > 512 MB ECC memory, and Hyperthread enabled. He > is running XP-Pro, sp2. > > Problem: Typically, the text files randomly get extra > blank lines added to them. Rarely, a few of the text > lines get truncated. And, even more rarely, whole > line will go missing. > > So, the author switched from VB's built in text > file writing code to WinAPI's Write File. Yippee!! > Now the text file only gets the occasional > random blank line added. > > Here is the rub: turning off the Hyperthread > in BIOS fixes the problem! (Editorial comment: > AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > > Is there some problem with VB6, Sp5 and Hyperthread? > And, is there a way to fix it? Compile it with some > Hyperthread libraries? All suggestions welcome! > > Many thanks, > --Tony I was going to ask this same question. Is this application doing something
clever with shared writes to that file, e.g. from multiple processes or multiple threads? If so then it might be a concurrency problem that's there all the time, but just shows up more frequently/reliably when HT is turned on. Assuming this is the case then the approach suggested below will work, but will not be optimum since opening files by name is a pretty slow operation. If speed is critical in that application then let us know and I'll dig up a class that does true shared writes to a text file, i.e. with all parties keeping a handle open to the same file. Tony Proctor Show quoteHide quote "Someone" <nob***@cox.net> wrote in message news:#CY5afQ0FHA.3488@TK2MSFTNGP09.phx.gbl... > > So, the author switched from VB's built in text > > file writing code to WinAPI's Write File. Yippee!! > > Now the text file only gets the occasional > > random blank line added. > > This to me sounds like 2 processes try to append to the same file, but may > not be the case with your situation. If so, you have to do the following: > > 1 - Lock the file. > 2 - Move the file pointer to the end of the file. Your process does not get > notified if another process added to the file, so the file pointer is not > moved in your process. > 3 - Append the text. > 4 - Unlock the file. > > Here is an example I posted in another thread: > > Option Explicit > > Private Sub Form_Load() > ' How to use > AppendLine "C:\Hello.txt", "Test1" > AppendLine "C:\Hello.txt", "Test2" > End Sub > > Private Sub AppendLine(ByRef FileName As String, ByRef LineToAdd As String) > On Error Resume Next > Dim f1 As Integer > Dim i As Long > Dim Locked As Boolean > > f1 = FreeFile > Open FileName For Append Access Read Write Shared As #f1 > If Err.Number <> 0 Then > MsgBox "AppendLine: Cannot Open/Create " & FileName & vbCrLf & > "Error " & Err.Number & ": " & Err.Description > Err.Clear > Exit Sub > End If > ' Retry locking the file; up to 100 times > Locked = False > For i = 1 To 100 > Lock #f1 ' Lock the entire file > If Err.Number <> 0 Then > ' Lock failed > Debug.Print "AppendLine: Lock retry "; i; " failed." > Err.Clear > ' Wait 0.05 second before trying again > Delay 0.05 > Else > ' Successfully locked > Locked = True > Exit For > End If > Next > > On Error GoTo 0 > If Locked Then > Seek #f1, LOF(f1) + 1 > ' Write the line > Print #f1, LineToAdd ' Use "Print #f1, LineToAdd;" if you don't want > a new line at the end > Unlock #f1 > Else > ' All retries failed to lock the file > MsgBox "AppendLine: Cannot lock file." > End If > > Close f1 > > End Sub > > Private Sub Delay(ByVal Seconds As Single) > Dim t As Single > > t = Timer > Do While Timer - t < Seconds > If t > Timer Then ' Adjust for midnight rollover to 0 > t = t - 86400 > End If > Loop > > End Sub > > > "Tony" <T***@invalid.com> wrote in message > news:dip440$ijj$1@domitilla.aioe.org... > > Hi All, > > > > Help! > > > > I have a customer with a semi custom application > > written in VB6, sp5. The program mainly writes text > > files to disk from things organized on the screen. > > His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > > 512 MB ECC memory, and Hyperthread enabled. He > > is running XP-Pro, sp2. > > > > Problem: Typically, the text files randomly get extra > > blank lines added to them. Rarely, a few of the text > > lines get truncated. And, even more rarely, whole > > line will go missing. > > > > So, the author switched from VB's built in text > > file writing code to WinAPI's Write File. Yippee!! > > Now the text file only gets the occasional > > random blank line added. > > > > Here is the rub: turning off the Hyperthread > > in BIOS fixes the problem! (Editorial comment: > > AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > > > > Is there some problem with VB6, Sp5 and Hyperthread? > > And, is there a way to fix it? Compile it with some > > Hyperthread libraries? All suggestions welcome! > > > > Many thanks, > > --Tony > >
Show quote
Hide quote
> "Someone" <nob***@cox.net> wrote in message Tony Proctor wrote:> news:#CY5afQ0FHA.3488@TK2MSFTNGP09.phx.gbl... > >>> So, the author switched from VB's built in text >>>file writing code to WinAPI's Write File. Yippee!! >>>Now the text file only gets the occasional >>>random blank line added. >> >>This to me sounds like 2 processes try to append to the same file, but may >>not be the case with your situation. If so, you have to do the following: >> >>1 - Lock the file. >>2 - Move the file pointer to the end of the file. Your process does not > > get > >>notified if another process added to the file, so the file pointer is not >>moved in your process. >>3 - Append the text. >>4 - Unlock the file. >> >>Here is an example I posted in another thread: >> >>Option Explicit >> >>Private Sub Form_Load() >> ' How to use >> AppendLine "C:\Hello.txt", "Test1" >> AppendLine "C:\Hello.txt", "Test2" >>End Sub >> >>Private Sub AppendLine(ByRef FileName As String, ByRef LineToAdd As > > String) > >>On Error Resume Next >> Dim f1 As Integer >> Dim i As Long >> Dim Locked As Boolean >> >> f1 = FreeFile >> Open FileName For Append Access Read Write Shared As #f1 >> If Err.Number <> 0 Then >> MsgBox "AppendLine: Cannot Open/Create " & FileName & vbCrLf & >>"Error " & Err.Number & ": " & Err.Description >> Err.Clear >> Exit Sub >> End If >> ' Retry locking the file; up to 100 times >> Locked = False >> For i = 1 To 100 >> Lock #f1 ' Lock the entire file >> If Err.Number <> 0 Then >> ' Lock failed >> Debug.Print "AppendLine: Lock retry "; i; " failed." >> Err.Clear >> ' Wait 0.05 second before trying again >> Delay 0.05 >> Else >> ' Successfully locked >> Locked = True >> Exit For >> End If >> Next >> >> On Error GoTo 0 >> If Locked Then >> Seek #f1, LOF(f1) + 1 >> ' Write the line >> Print #f1, LineToAdd ' Use "Print #f1, LineToAdd;" if you don't > > want > >>a new line at the end >> Unlock #f1 >> Else >> ' All retries failed to lock the file >> MsgBox "AppendLine: Cannot lock file." >> End If >> >> Close f1 >> >>End Sub >> >>Private Sub Delay(ByVal Seconds As Single) >> Dim t As Single >> >> t = Timer >> Do While Timer - t < Seconds >> If t > Timer Then ' Adjust for midnight rollover to 0 >> t = t - 86400 >> End If >> Loop >> >>End Sub >> >> >>"Tony" <T***@invalid.com> wrote in message >>news:dip440$ijj$1@domitilla.aioe.org... >> >>>Hi All, >>> >>> Help! >>> >>> I have a customer with a semi custom application >>>written in VB6, sp5. The program mainly writes text >>>files to disk from things organized on the screen. >>>His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, >>>512 MB ECC memory, and Hyperthread enabled. He >>>is running XP-Pro, sp2. >>> >>> Problem: Typically, the text files randomly get extra >>>blank lines added to them. Rarely, a few of the text >>>lines get truncated. And, even more rarely, whole >>>line will go missing. >>> >>> So, the author switched from VB's built in text >>>file writing code to WinAPI's Write File. Yippee!! >>>Now the text file only gets the occasional >>>random blank line added. >>> >>> Here is the rub: turning off the Hyperthread >>>in BIOS fixes the problem! (Editorial comment: >>>AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) >>> >>> Is there some problem with VB6, Sp5 and Hyperthread? >>>And, is there a way to fix it? Compile it with some >>>Hyperthread libraries? All suggestions welcome! >>> >>>Many thanks, >>>--Tony >> > I was going to ask this same question. Is this application doing dig up asomething > clever with shared writes to that file, e.g. from multiple processes or > multiple threads? If so then it might be a concurrency problem that's there > all the time, but just shows up more frequently/reliably when HT is turned > on. > > Assuming this is the case then the approach suggested below will work, but > will not be optimum since opening files by name is a pretty slow operation. > If speed is critical in that application then let us know and I'll > class that does true shared writes to a text file, i.e. with all parties Hi All,> keeping a handle open to the same file. > > Tony Proctor > Thank you for the tip! Not to ask too stupid a question, but is not file locking reserved for files on a network? This is a stand alone application on a single machine. I can not perceive why any other application, other than this one would be writing to the file in question. And, there is only one sub that writes the file in questions and it is only called when the user presses "save." I am a bit confused. Many thanks, --Tony > is not file locking reserved No. If the user opened 2 copies of your App, then you have the same > for files on a network? situation faced with multi-user programs. One copy of your App might think that it's at the end of the file when it's not, for example, if the end of the file is at byte 1001(File size now is 1000 bytes), another copy of your App could write 5 bytes and advances it's own file pointer to 1006. The first copy of your App still thinks that the file is 1000 bytes long. Windows does not notify your App that the file has been expanded by another process. If the first copy writes to the file, it will write starting at position 1001, overwriting what the second copy has written. To solve this, you must lock the file, move the file's pointer to the end of the file in case another process expanded the file, then append what you want. The sample that I used illustrates this, but you may want to move Open/Close statements outside the AppendLine routine for performance reasons. > This is a stand alone application on The user could have another copy open.> a single machine. I can not perceive why any other application, > other than this one would be writing to the file in question. > And, there is only one sub that writes the file in questions and it If you are sure that it's only one routine, then you must have a problem in > is only called when the user presses "save." I am a bit confused. the code somewhere. Post the code or a trimmed down version that reproduces the problem. Show quoteHide quote "Tony" <T***@invalid.com> wrote in message news:4353E58F.6040201@invalid.com... > >> "Someone" <nob***@cox.net> wrote in message >> news:#CY5afQ0FHA.3488@TK2MSFTNGP09.phx.gbl... >> >>>> So, the author switched from VB's built in text >>>>file writing code to WinAPI's Write File. Yippee!! >>>>Now the text file only gets the occasional >>>>random blank line added. >>> >>>This to me sounds like 2 processes try to append to the same file, but >>>may >>>not be the case with your situation. If so, you have to do the following: >>> >>>1 - Lock the file. >>>2 - Move the file pointer to the end of the file. Your process does not >> >> get >> >>>notified if another process added to the file, so the file pointer is not >>>moved in your process. >>>3 - Append the text. >>>4 - Unlock the file. >>> >>>Here is an example I posted in another thread: >>> >>>Option Explicit >>> >>>Private Sub Form_Load() >>> ' How to use >>> AppendLine "C:\Hello.txt", "Test1" >>> AppendLine "C:\Hello.txt", "Test2" >>>End Sub >>> >>>Private Sub AppendLine(ByRef FileName As String, ByRef LineToAdd As >> >> String) >> >>>On Error Resume Next >>> Dim f1 As Integer >>> Dim i As Long >>> Dim Locked As Boolean >>> >>> f1 = FreeFile >>> Open FileName For Append Access Read Write Shared As #f1 >>> If Err.Number <> 0 Then >>> MsgBox "AppendLine: Cannot Open/Create " & FileName & vbCrLf & >>>"Error " & Err.Number & ": " & Err.Description >>> Err.Clear >>> Exit Sub >>> End If >>> ' Retry locking the file; up to 100 times >>> Locked = False >>> For i = 1 To 100 >>> Lock #f1 ' Lock the entire file >>> If Err.Number <> 0 Then >>> ' Lock failed >>> Debug.Print "AppendLine: Lock retry "; i; " failed." >>> Err.Clear >>> ' Wait 0.05 second before trying again >>> Delay 0.05 >>> Else >>> ' Successfully locked >>> Locked = True >>> Exit For >>> End If >>> Next >>> >>> On Error GoTo 0 >>> If Locked Then >>> Seek #f1, LOF(f1) + 1 >>> ' Write the line >>> Print #f1, LineToAdd ' Use "Print #f1, LineToAdd;" if you don't >> >> want >> >>>a new line at the end >>> Unlock #f1 >>> Else >>> ' All retries failed to lock the file >>> MsgBox "AppendLine: Cannot lock file." >>> End If >>> >>> Close f1 >>> >>>End Sub >>> >>>Private Sub Delay(ByVal Seconds As Single) >>> Dim t As Single >>> >>> t = Timer >>> Do While Timer - t < Seconds >>> If t > Timer Then ' Adjust for midnight rollover to 0 >>> t = t - 86400 >>> End If >>> Loop >>> >>>End Sub >>> >>> >>>"Tony" <T***@invalid.com> wrote in message >>>news:dip440$ijj$1@domitilla.aioe.org... >>> >>>>Hi All, >>>> >>>> Help! >>>> >>>> I have a customer with a semi custom application >>>>written in VB6, sp5. The program mainly writes text >>>>files to disk from things organized on the screen. >>>>His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, >>>>512 MB ECC memory, and Hyperthread enabled. He >>>>is running XP-Pro, sp2. >>>> >>>> Problem: Typically, the text files randomly get extra >>>>blank lines added to them. Rarely, a few of the text >>>>lines get truncated. And, even more rarely, whole >>>>line will go missing. >>>> >>>> So, the author switched from VB's built in text >>>>file writing code to WinAPI's Write File. Yippee!! >>>>Now the text file only gets the occasional >>>>random blank line added. >>>> >>>> Here is the rub: turning off the Hyperthread >>>>in BIOS fixes the problem! (Editorial comment: >>>>AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) >>>> >>>> Is there some problem with VB6, Sp5 and Hyperthread? >>>>And, is there a way to fix it? Compile it with some >>>>Hyperthread libraries? All suggestions welcome! >>>> >>>>Many thanks, >>>>--Tony >>> > Tony Proctor wrote: > > I was going to ask this same question. Is this application doing > something > > clever with shared writes to that file, e.g. from multiple processes or > > multiple threads? If so then it might be a concurrency problem that's > there > > all the time, but just shows up more frequently/reliably when HT is > turned > > on. > > > > Assuming this is the case then the approach suggested below will > work, but > > will not be optimum since opening files by name is a pretty slow > operation. > > If speed is critical in that application then let us know and I'll > dig up a > > class that does true shared writes to a text file, i.e. with all parties > > keeping a handle open to the same file. > > > > Tony Proctor > > > > Hi All, > > Thank you for the tip! > > Not to ask too stupid a question, but is not file locking reserved > for files on a network? This is a stand alone application on > a single machine. I can not perceive why any other application, > other than this one would be writing to the file in question. > And, there is only one sub that writes the file in questions and it > is only called when the user presses "save." I am a bit confused. > > Many thanks, > --Tony That couldn't really happen with a simple VB application that opened/closed
the file every time it wanted to write a record. All buffered data is effectively flushed to the file when it's closed. If 2 instances of the same application attempted the writes then one might get a 'file locked' error if they attempted it at the same time. However, that's not what the OP was seeing, and your own sample code would cope with that anyway. The only way I can think of to get random characters, truncated lines, blanks lines, etc., is if 2 pieces of code had the file open at the same time. Then there would certainly be issues about 'who knows where the real end-of-file is'. I have code that would solve this, but I wanted a bit more information from the OP first. If it's a Standard EXE then you would probably have to resort to Win32 calls to achieve that level of sharing. If the application has multiple threads (e.g. in a multi-threaded ActiveX EXE, or running inside IIS) then the normal VB file locking breaks down, and accidental file sharing can result. Tony Proctor Show quoteHide quote "Someone" <nob***@cox.net> wrote in message news:u2F68c00FHA.3300@TK2MSFTNGP15.phx.gbl... > > is not file locking reserved > > for files on a network? > > No. If the user opened 2 copies of your App, then you have the same > situation faced with multi-user programs. One copy of your App might think > that it's at the end of the file when it's not, for example, if the end of > the file is at byte 1001(File size now is 1000 bytes), another copy of your > App could write 5 bytes and advances it's own file pointer to 1006. The > first copy of your App still thinks that the file is 1000 bytes long. > Windows does not notify your App that the file has been expanded by another > process. If the first copy writes to the file, it will write starting at > position 1001, overwriting what the second copy has written. > > To solve this, you must lock the file, move the file's pointer to the end of > the file in case another process expanded the file, then append what you > want. The sample that I used illustrates this, but you may want to move > Open/Close statements outside the AppendLine routine for performance > reasons. > > > > This is a stand alone application on > > a single machine. I can not perceive why any other application, > > other than this one would be writing to the file in question. > > > The user could have another copy open. > > > > And, there is only one sub that writes the file in questions and it > > is only called when the user presses "save." I am a bit confused. > > > If you are sure that it's only one routine, then you must have a problem in > the code somewhere. Post the code or a trimmed down version that reproduces > the problem. > > > > "Tony" <T***@invalid.com> wrote in message > news:4353E58F.6040201@invalid.com... > > > >> "Someone" <nob***@cox.net> wrote in message > >> news:#CY5afQ0FHA.3488@TK2MSFTNGP09.phx.gbl... > >> > >>>> So, the author switched from VB's built in text > >>>>file writing code to WinAPI's Write File. Yippee!! > >>>>Now the text file only gets the occasional > >>>>random blank line added. > >>> > >>>This to me sounds like 2 processes try to append to the same file, but > >>>may > >>>not be the case with your situation. If so, you have to do the following: > >>> > >>>1 - Lock the file. > >>>2 - Move the file pointer to the end of the file. Your process does not > >> > >> get > >> > >>>notified if another process added to the file, so the file pointer is not > >>>moved in your process. > >>>3 - Append the text. > >>>4 - Unlock the file. > >>> > >>>Here is an example I posted in another thread: > >>> > >>>Option Explicit > >>> > >>>Private Sub Form_Load() > >>> ' How to use > >>> AppendLine "C:\Hello.txt", "Test1" > >>> AppendLine "C:\Hello.txt", "Test2" > >>>End Sub > >>> > >>>Private Sub AppendLine(ByRef FileName As String, ByRef LineToAdd As > >> > >> String) > >> > >>>On Error Resume Next > >>> Dim f1 As Integer > >>> Dim i As Long > >>> Dim Locked As Boolean > >>> > >>> f1 = FreeFile > >>> Open FileName For Append Access Read Write Shared As #f1 > >>> If Err.Number <> 0 Then > >>> MsgBox "AppendLine: Cannot Open/Create " & FileName & vbCrLf & > >>>"Error " & Err.Number & ": " & Err.Description > >>> Err.Clear > >>> Exit Sub > >>> End If > >>> ' Retry locking the file; up to 100 times > >>> Locked = False > >>> For i = 1 To 100 > >>> Lock #f1 ' Lock the entire file > >>> If Err.Number <> 0 Then > >>> ' Lock failed > >>> Debug.Print "AppendLine: Lock retry "; i; " failed." > >>> Err.Clear > >>> ' Wait 0.05 second before trying again > >>> Delay 0.05 > >>> Else > >>> ' Successfully locked > >>> Locked = True > >>> Exit For > >>> End If > >>> Next > >>> > >>> On Error GoTo 0 > >>> If Locked Then > >>> Seek #f1, LOF(f1) + 1 > >>> ' Write the line > >>> Print #f1, LineToAdd ' Use "Print #f1, LineToAdd;" if you don't > >> > >> want > >> > >>>a new line at the end > >>> Unlock #f1 > >>> Else > >>> ' All retries failed to lock the file > >>> MsgBox "AppendLine: Cannot lock file." > >>> End If > >>> > >>> Close f1 > >>> > >>>End Sub > >>> > >>>Private Sub Delay(ByVal Seconds As Single) > >>> Dim t As Single > >>> > >>> t = Timer > >>> Do While Timer - t < Seconds > >>> If t > Timer Then ' Adjust for midnight rollover to 0 > >>> t = t - 86400 > >>> End If > >>> Loop > >>> > >>>End Sub > >>> > >>> > >>>"Tony" <T***@invalid.com> wrote in message > >>>news:dip440$ijj$1@domitilla.aioe.org... > >>> > >>>>Hi All, > >>>> > >>>> Help! > >>>> > >>>> I have a customer with a semi custom application > >>>>written in VB6, sp5. The program mainly writes text > >>>>files to disk from things organized on the screen. > >>>>His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > >>>>512 MB ECC memory, and Hyperthread enabled. He > >>>>is running XP-Pro, sp2. > >>>> > >>>> Problem: Typically, the text files randomly get extra > >>>>blank lines added to them. Rarely, a few of the text > >>>>lines get truncated. And, even more rarely, whole > >>>>line will go missing. > >>>> > >>>> So, the author switched from VB's built in text > >>>>file writing code to WinAPI's Write File. Yippee!! > >>>>Now the text file only gets the occasional > >>>>random blank line added. > >>>> > >>>> Here is the rub: turning off the Hyperthread > >>>>in BIOS fixes the problem! (Editorial comment: > >>>>AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > >>>> > >>>> Is there some problem with VB6, Sp5 and Hyperthread? > >>>>And, is there a way to fix it? Compile it with some > >>>>Hyperthread libraries? All suggestions welcome! > >>>> > >>>>Many thanks, > >>>>--Tony > >>> > > Tony Proctor wrote: > > > I was going to ask this same question. Is this application doing > > something > > > clever with shared writes to that file, e.g. from multiple processes or > > > multiple threads? If so then it might be a concurrency problem that's > > there > > > all the time, but just shows up more frequently/reliably when HT is > > turned > > > on. > > > > > > Assuming this is the case then the approach suggested below will > > work, but > > > will not be optimum since opening files by name is a pretty slow > > operation. > > > If speed is critical in that application then let us know and I'll > > dig up a > > > class that does true shared writes to a text file, i.e. with all parties > > > keeping a handle open to the same file. > > > > > > Tony Proctor > > > > > > > Hi All, > > > > Thank you for the tip! > > > > Not to ask too stupid a question, but is not file locking reserved > > for files on a network? This is a stand alone application on > > a single machine. I can not perceive why any other application, > > other than this one would be writing to the file in question. > > And, there is only one sub that writes the file in questions and it > > is only called when the user presses "save." I am a bit confused. > > > > Many thanks, > > --Tony > > On Mon, 17 Oct 2005 10:55:27 -0700, Tony <T***@invalid.com> wrote:
<snip> > Not to ask too stupid a question, but is not file locking reserved No - it is not reserved for files on a network>for files on a network? - best to use it all the time >This is a stand alone application on I think that the suggestion that you might have two instances of the>a single machine. I can not perceive why any other application, >other than this one would be writing to the file in question. >And, there is only one sub that writes the file in questions and it >is only called when the user presses "save." I am a bit confused. App is well worth researching. Also I would like to see the /exact/ code you are using for writing to the file - if you have a DoEvents in it then the problem could be 'user created' by them clicking 'Save' twice. You could also probably locate the cause of the problem by putting a bit more info in the Log File (a header and footer for each write would be a minimum) J French wrote:
> Also I would like to see the /exact/ code you are using for writing to I have two modifications to the code (flushing and> the file process affinity) that will take me about two weeks to test. If Happy Camping has not been achieved by then, I will repost the section of code. Many thanks, --Tony On Tue, 18 Oct 2005 11:40:51 -0700, Tony <T***@invalid.com> wrote:
>J French wrote: IMO the best way of flushing a file is to close it.> >> Also I would like to see the /exact/ code you are using for writing to >> the file > >I have two modifications to the code (flushing and >process affinity) that will take me about two weeks >to test. If Happy Camping has not been achieved by >then, I will repost the section of code. (the old DOS Flush was create duplicate handle and close) Also, with sensitive data it is wise to pre-extend the file, close it, re-open it and then write within existing file space. This sounds a chore, but realistically one extends the file by about 50k to 100k so it does not happen very often. Unless yours is the only App running on this box, and you have not soak tested it, then it is extremely unlikely that the hyperthreading is really responsible - if it is responsible then the box is 'sick' and you would have seen symptoms elsewhere. I strongly suggest that you post your current routine so we can pick over it.
Show quote
Hide quote
> I have a customer with a semi custom application You may want to try setting the process affinity to only use a single CPU, have a look at this old post on the subject:> written in VB6, sp5. The program mainly writes text > files to disk from things organized on the screen. > His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > 512 MB ECC memory, and Hyperthread enabled. He > is running XP-Pro, sp2. > > Problem: Typically, the text files randomly get extra > blank lines added to them. Rarely, a few of the text > lines get truncated. And, even more rarely, whole > line will go missing. > > So, the author switched from VB's built in text > file writing code to WinAPI's Write File. Yippee!! > Now the text file only gets the occasional > random blank line added. > > Here is the rub: turning off the Hyperthread > in BIOS fixes the problem! (Editorial comment: > AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > > Is there some problem with VB6, Sp5 and Hyperthread? > And, is there a way to fix it? Compile it with some > Hyperthread libraries? All suggestions welcome! http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/83e88190612c4212 You may olso want to try adding a few flushes into your existing I/O code, here's an old post on that: http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/af6d6e1ede4be84b Hope this helps, Mike P.s. I'm running a dual 2.4Ghz box with hyperthreading on both CPU's here and haven't had a single problem with any VB 6, SP5 application (unless things have changed significantly in XP SP2 which I've currently managed to avoid having to install.) - Microsoft Visual Basic MVP - E-Mail: ED***@mvps.org WWW: Http://EDais.mvps.org/ I would say the FlushFileBuffers is a bit of folklore Mike. It is only
required in you want to guarantee that your file data is periodically flushed through the cache and onto disk, e.g. in anticipation of a crash or something. Note I said "flushed through" rather than "flushed from". It doesn't empty the data from the cache. As far as I'm aware, the equivalent of this happens when you close a (win32-)file handle. Even if it didn't, though, the file system cache is machine-wide. Hence, the very next Open operation will use the same cached data. In other words, there should be no loss or corruption of data. To the OP: I too would like to see how you're opening your file now with Win32. If it is allowing shared access (which isn't the norm) then data corruptions can be possible, but it requires more than one accessor. If there is only a single application accessing the file (and it's single-threaded, and there's only one instance of it), then I'm afraid it feels more like a coding bug in the application :-( Tony Proctor Show quoteHide quote "Mike D Sutton" <ED***@mvps.org> wrote in message have a look at this old post on the subject:news:ePgMK$Q0FHA.720@TK2MSFTNGP15.phx.gbl... > > I have a customer with a semi custom application > > written in VB6, sp5. The program mainly writes text > > files to disk from things organized on the screen. > > His computer is a 2.8 GHz Pentium 4, 800 MHz FSB, > > 512 MB ECC memory, and Hyperthread enabled. He > > is running XP-Pro, sp2. > > > > Problem: Typically, the text files randomly get extra > > blank lines added to them. Rarely, a few of the text > > lines get truncated. And, even more rarely, whole > > line will go missing. > > > > So, the author switched from VB's built in text > > file writing code to WinAPI's Write File. Yippee!! > > Now the text file only gets the occasional > > random blank line added. > > > > Here is the rub: turning off the Hyperthread > > in BIOS fixes the problem! (Editorial comment: > > AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!) > > > > Is there some problem with VB6, Sp5 and Hyperthread? > > And, is there a way to fix it? Compile it with some > > Hyperthread libraries? All suggestions welcome! > > You may want to try setting the process affinity to only use a single CPU, > http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/83e88190612c4212> You may olso want to try adding a few flushes into your existing I/O code, here's an old post on that:> http://groups.google.co.uk/group/microsoft.public.vb.winapi/msg/af6d6e1ede4be84b> Hope this helps, and haven't had a single problem with any VB> > Mike > > P.s. I'm running a dual 2.4Ghz box with hyperthreading on both CPU's here > 6, SP5 application (unless things have changed significantly in XP SP2 which I've currently managed to avoid having toShow quoteHide quote > install.) > > > - Microsoft Visual Basic MVP - > E-Mail: ED***@mvps.org > WWW: Http://EDais.mvps.org/ > > > I am having (WinAPI) flushes added to each (WinAPI) WriteFile Since you are using the WinAPI instead of VB's built-in File I/O, lookup these functions in MSDN if you want to translate the routine that I posted earlier. GetFileSize ' LOF() Equivalent SetFilePointer ' Seek Statement Equivalent LockFile UnlockFile There is no "GetFilePointer", instead you have to use: Public Function GetFilePointer(ByVal hFile As Long) As Long GetFilePointer = SetFilePointer(hFile, 0, ByVal 0&, FILE_CURRENT) End Function Also, check this example: Appending One File to Another File http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/appending_one_file_to_another_file.asp Also, are you using this flag in your CreateFile call? Could you post the call and the flags used? FILE_FLAG_OVERLAPPED If you used that one, you could have problems. Someone wrote:
Show quoteHide quote > Since you are using the WinAPI instead of VB's built-in File I/O, lookup Thank you!> these functions in MSDN if you want to translate the routine that I posted > earlier. > > GetFileSize ' LOF() Equivalent > SetFilePointer ' Seek Statement Equivalent > LockFile > UnlockFile > > There is no "GetFilePointer", instead you have to use: > > Public Function GetFilePointer(ByVal hFile As Long) As Long > GetFilePointer = SetFilePointer(hFile, 0, ByVal 0&, FILE_CURRENT) > End Function > > Also, check this example: > > Appending One File to Another File > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/appending_one_file_to_another_file.asp > > Also, are you using this flag in your CreateFile call? Could you post the > call and the flags used? > > FILE_FLAG_OVERLAPPED > > If you used that one, you could have problems. > Here's a link to some sample code that provides a file-sharing class:
http://groups.google.ie/group/microsoft.public.vb.com/msg/e2e67b2bdfc0ae5b?hl=en& It takes care of locks, end-of-file, and always guarantees writes are safely flushed through to disk. However, it's really only appropriate where a file is being shared for write access by multiple processes, or multiple threads. I'm not convinced the OP's problem is one of file sharing though. Tony Proctor Show quoteHide quote "Someone" <nob***@cox.net> wrote in message http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/appending_one_file_to_another_file.aspnews:OpRIZKC1FHA.268@TK2MSFTNGP09.phx.gbl... > > I am having (WinAPI) flushes added to each (WinAPI) WriteFile > > Since you are using the WinAPI instead of VB's built-in File I/O, lookup > these functions in MSDN if you want to translate the routine that I posted > earlier. > > GetFileSize ' LOF() Equivalent > SetFilePointer ' Seek Statement Equivalent > LockFile > UnlockFile > > There is no "GetFilePointer", instead you have to use: > > Public Function GetFilePointer(ByVal hFile As Long) As Long > GetFilePointer = SetFilePointer(hFile, 0, ByVal 0&, FILE_CURRENT) > End Function > > Also, check this example: > > Appending One File to Another File > Show quoteHide quote > > Also, are you using this flag in your CreateFile call? Could you post the > call and the flags used? > > FILE_FLAG_OVERLAPPED > > If you used that one, you could have problems. > > > 
Other interesting topics
Organizing Constants for Easier Maintenance
insert char in txtbox on key up? ?creating activex control? Font Dialog Box kill a proccess for a specific user VB6: What's the command that creates an ARRAY out of a STRING??? XP Styles and Web Browser control Newbie: ADO - Access Connection string GDI API question X 2 Software protection against cracks and piracy |
|||||||||||||||||||||||
