VB6 Data missing when writing to a text file.
in [Visual Basic]
|
From: bitshifter on 16 Jan 2010 12:59 On Fri, 15 Jan 2010 10:20:37 -0600, DanS <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote: >"MikeD" <nobody(a)nowhere.edu> wrote in >news:ueCOLwflKHA.2316(a)TK2MSFTNGP06.phx.gbl: >(Not complete, but the jist (sp?) is there.) ....gist >Public Function WriteLog(entry as string) as boolean > > On Error Resume Next > Open File for Append > Print #, entry > Close # > > If err then > err.clear > WriteLog = False > Else > WriteLog = True > End if > >End Function > > >Or something similar. This way not only is it just one line to write to >the log, but the OP can place a break or a debug.print in this one >function to see if the log is being written when they think it should be. Nice error handling.
From: DanS on 16 Jan 2010 21:01 bitshifter(a)sympatico.ca wrote in news:4b51fe13.4314609(a)news.newshosting.com: > On Fri, 15 Jan 2010 10:20:37 -0600, DanS > <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote: > >>"MikeD" <nobody(a)nowhere.edu> wrote in >>news:ueCOLwflKHA.2316(a)TK2MSFTNGP06.phx.gbl: > >>(Not complete, but the jist (sp?) is there.) > ...gist > >>Public Function WriteLog(entry as string) as boolean >> >> On Error Resume Next >> Open File for Append >> Print #, entry >> Close # >> >> If err then >> err.clear >> WriteLog = False >> Else >> WriteLog = True >> End if >> >>End Function >> >> >>Or something similar. This way not only is it just one line to write >>to the log, but the OP can place a break or a debug.print in this one >>function to see if the log is being written when they think it should >>be. > > Nice error handling. That doesn't work for you ?
From: Helmut Meukel on 30 Jan 2010 18:42 Hmmm, that's fine if the frequency is low, but with openening and closing the text file for each line you impose some overhead on the OS. Some years ago (in 2002) I did this with an app that told a PLC how much liquid dyestuff and chemical to send to about more than 10 dyeing machines. We had to protocol every step and wrote the lines to one large file. Some weeks later my partner was called to the customer to fix intermitting errors with the system. He phoned me and we fixed it by opening the file in the morning and closing it when the app was shut-down at the end of the second shift. I wasn't happy with this 'fix' but we had never since problems with the logging. Helmut. "DanS" <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> schrieb im Newsbeitrag news:Xns9D01737E2A942thisnthatroadrunnern(a)216.196.97.131... > "MikeD" <nobody(a)nowhere.edu> wrote in > news:ueCOLwflKHA.2316(a)TK2MSFTNGP06.phx.gbl: > >> >> "Jennifer Ward" <jward(a)comcast.net> wrote in message >> news:Oro7cXflKHA.2184(a)TK2MSFTNGP04.phx.gbl... >>> Hi, >>> >>> I'm having a problem when writing text to a text file. >>> My program opens the file and then periodically from different >>> routines a line will be written to it. >>> I close the file before ending the program. The problem is that some >>> of the lines are not getting to the file. >>> Could it be that the program is ending too quickly after Close >>> statement ? >>> >>> Sample code: >>> >>> fname = "\Event_Log.txt" >>> Err_Log_Filenum = FreeFile() >>> Open App.Path & fname For Append As Err_Log_Filenum >>> >>> Then periodically: >>> >>> Print #Err_Log_Filenum, Format$(Now, "mm-dd-yy hh:mm:ss") & "Error >>> text" >>> >>> Finally: >>> Close #Err_Log_Filenum >>> >>> >> >> >> It appears you're opening the file once, perhaps when your program >> first runs, write to it periodically, and then close the file when >> your program closes. I would not recommend this. Instead open and >> close the file EACH time you need to write to it. This may or may not >> solve your actual problem, but it's a better and safer method. >> > > Yes Mike, I would agree. > > The OP should write a sub/function... > > (Not complete, but the jist (sp?) is there.) > > Public Function WriteLog(entry as string) as boolean > > On Error Resume Next > Open File for Append > Print #, entry > Close # > > If err then > err.clear > WriteLog = False > Else > WriteLog = True > End if > > End Function > > > Or something similar. This way not only is it just one line to write to > the log, but the OP can place a break or a debug.print in this one > function to see if the log is being written when they think it should be. > > >
From: Tony Toews [MVP] on 30 Jan 2010 20:52 "Helmut Meukel" <NoSpam(a)NoProvider.de> wrote: >Hmmm, that's fine if the frequency is low, but with openening and >closing the text file for each line you impose some overhead on the OS. >Some years ago (in 2002) I did this with an app that told a PLC how >much liquid dyestuff and chemical to send to about more than 10 dyeing >machines. We had to protocol every step and wrote the lines to one >large file. Some weeks later my partner was called to the customer to fix >intermitting errors with the system. >He phoned me and we fixed it by opening the file in the morning and >closing it when the app was shut-down at the end of the second shift. >I wasn't happy with this 'fix' but we had never since problems with the >logging. My concern there would be that if the system or your app failed you would likely loose the entire contents of the log file. I wonder if a log file per day would be a better solution and opening and closing it for each entry would've worked as the daily log file would be much smaller. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews [MVP] on 30 Jan 2010 21:08 "Helmut Meukel" <NoSpam(a)NoProvider.de> wrote: >He phoned me and we fixed it by opening the file in the morning and >closing it when the app was shut-down at the end of the second shift. >I wasn't happy with this 'fix' but we had never since problems with the >logging. There was a hilarious story somewhere long those same lines. Maybe on The Reg or comp.risks. The card scanners in an office to unlock the doors didn't work very well. You'd scan your card in, wait a few seconds,try it again and again then, finally, the door would unlock. People were always cursing the slowness of the doors to unlock. A programmer was working late or over the weekend and noticed that the various doors were unlocking randomly as he could hear the clicks coming from various places and at random intervals. He was rather curious so went poking about on the card control computer. He discovered that the log file was a huge, huge file many megabytes in size. So either he renamed the file or truncated it down to 0 bytes. The locks in the office went into a veritable hailstorm of unlocking and suddenly stopped. The comments the next working day were that somehow the locks had been fixed as they promptly unlocked after scanning your card. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Installing MDAC 5 for sp5 Next: Dumb question: Are VB6 DLLs dependient on the rutnime? |