 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General 2 / April 2004memory allocation
Dear All, As an attempt to get around a very odd bug which seems to hit when I print to a text file over and over again, I want to allocate a certain amount of disk memory for a file at the time when the file is first created. Is this possible? All I am trying to do is to write some data to a simple .txt file at intervals of a minute or so, over a period of several days. At random times I get 'error 70', where VB6 isn't happy with the file name. If I trap this error and use a different file name, I can continue as before. Thanks in advance John Fox  SignatureAll prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk >As an attempt to get around a very odd bug which seems to hit when I >print to a text file over and over again, I want to allocate a certain >amount of disk memory for a file at the time when the file is first >created. >Is this possible? Sounds odd. Care to post some code? Regards SignatureMartin Trump > As an attempt to get around a very odd bug which seems to hit > when I print to a text file over and over again, I want to allocate > a certain amount of disk memory for a file at the time when the > file is first created. Is this possible? Yes. You can create the file any size you want using any of a number of diferrent ways, for example you can create a 100K file (full of "space" characters) using: Dim s1 As String s1 = Space$(102400) Open "c:\craptest" For Binary As 1 Put #1, 1, s1 Close 1 Then you can write stuff (or add stuff) to it without altering its initial size using the VB Put statement, which is capable of entering any desired number of bytes into the file at any desired position. However, I don't think your problem has anything to do with the initial size of the file. It is more likely that your own program (or perhaps some other program) has the file open and perhaps even locked at the same time you are accessing it, or even that the Windows write caching stuff is getting in the way. What method are you using to write your data? Are you completely rewriting the file each time or are you appending data to it by adding to the data already there? Post some of your code. Mike This is essentially the code. 'Find the first available filenumber 'get the correct file name to use 'open the file, print the data then close the file again fileno = FreeFile ' finds next available file number logfilename = Form1.pepname.Text ' works out the file name to use Open logfilename For Append Lock Read Write As #fileno ' saves the time and the data Print #fileno, Form1.clock.Text; fileno; logmessage Close #fileno This works 99.99% of the time, however every 1000 or so operations I get an error70 message which is normally fatal. If I trap the error, alter the filename to say filename2, then it works again. I have run this on Win95, Win2000 and WinXP and the bug still appears. However it is most common on an old Win95 machine where it appears about once per day. The program would do this save every 2-3 minutes on average. I use it to log data from a scientific instrument. John Fox > This is essentially the code. > 'Find the first available filenumber [quoted text clipped - 8 lines] > Print #fileno, Form1.clock.Text; fileno; logmessage > Close #fileno Isn't it just because you try to lock the file ? Is someone else (person or program) locking it also ? If you get the error then what happens if you wait 5 sec (or more) and try again ? Signature/\ preben nielsen \/\ prel@post.tele.dk > Isn't it just because you try to lock the file ? Is someone else > (person or program) locking it also ? No, it happens on a stand alone PC and only the VB6 program is operating. I have tried all sorts of combinations, locking, not locking The failure still seems to take place. > If you get the error then what happens if you wait 5 sec (or more) > and try again ? I have tried that. The working programme does actually wait 5 sec but it doesn't seem to have any effect. The closest explanation is that Windows gets bored of opening and closing one file name 1000's of times :-) John > The closest explanation is that Windows gets bored of opening and > closing one file name 1000's of times :-) You could possibly be running into problems because Winders is buffering disk writes and not actually writing the data at the time you close the file. The write buffer may be filling up with consecutive writes to the same file and this may be confusing Winders. Try flushing the buffers after every file open / close, or perhaps after every five or six open / close operations, or possibly switching off disk write buffering altogether. Mike Dear Mike, How do I flush the buffers out? Your buffer theory may be onto something, it seems to fit the facts. John >>The closest explanation is that Windows gets bored of opening and >>closing one file name 1000's of times :-) [quoted text clipped - 7 lines] > > Mike SignatureAll prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk > How do I flush the buffers out? Your buffer theory may be > onto something, it seems to fit the facts. I don't think you can do it using standard VB File I/O stuff because VB doesn't return the "real" operating system handle to the file. I think you will need to open your file using the API (CreateFile) and write your stuff to the file using the various API routines. As far as I know, if you specify both FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH in the dwFlagsandAttributes parameter then the data is immediately flushed to disk without going through the system cache. The system also requests a low level hardware write through of the hardware disk cache, although not all hardware supports this. Have a look at the following for more information (watch for line wrap on the URL): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/cre atefile.asp I'm not sure whether this stuff will solve your problem though. I've just tried something similar to your own code, using standard VB I/O stuff as you are doing, and I can append 10K of data to a file at the rate of 600 appends per minute (ten per second) and I can leave it running for ages (thousands and thousands of writes) without any problems at all. I could probably get a lot more than that if I tried. Anyone else care to try something similar on their own systems? Perhaps you might care to post all (or at least the bulk) of your code John so that people here can look at it in more detail. For example, what sort of a Timer are you using. It isn't by any chance a Multimedia Timer is it? Mike Dear Mike, The whole code is pretty big, 400k I have a text box called 'clock' which is run by a VB timer clock = Date + Time and simply print the value onto the file. I just need the time of day and date for the log file. The logging operation is simply a subroutine within a module and I call the sub from the main program with the data as arguments, the data is simply a few words of text. The problem does seem to be worse on older PCs such as a Win95, Dell P75 with 500M disk, but it has struck on a new WinXP, Optiplex G240 with a 40G drive. John >>How do I flush the buffers out? Your buffer theory may be >>onto something, it seems to fit the facts. [quoted text clipped - 24 lines] > > Mike > I have a text box called 'clock' which is run by a VB timer > clock = Date + Time > and simply print the value onto the file. I just need the time of day > and date for the log file. It all sounds very odd to me, especially as I find that I am unable to reproduce the fault on either my WinXP or my much older Win98 machine, no matter how much data I write to the file each time and no matter how many times per minute I access it. What happens if you trap the error and repeatedly attempt to open the file (using the same filename and stuff) and count and record the number of attempts and the time it takes for the error to clear itself? Mike Yes it is very strange, I have been probing this one for about 2 years now, it's like a ghost. I have gone back and tried a little test program and can't make it fail after 60000 attempts. Yet on average we get a failure on the instruments once very 2000 or so writes. In the past I have got test programs to fail but it is much rarer than the real thing. I have tried repeating with the same filename, trying again after a delay of 5 seconds and I think it just fell over. This was ages ago though. The current error trap automatically waits for 5sec, modifies the file name to n+1 and carries on. The instruments are talking to the PC over a serial line through COM1 and use proprietory device drivers. However the logfile is dealt with before the instruments are activated. Nothin else is talking to the log file. John > It all sounds very odd to me, especially as I find that I am unable to > reproduce the fault on either my WinXP or my much older Win98 machine, no [quoted text clipped - 5 lines] > > Mike SignatureDr John E. Fox Director All prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk > The instruments are talking to the PC over a serial line through > COM1 and use proprietory device drivers. However the logfile > is dealt with before the instruments are activated. Well it's difficult to see a problem there. There could be a hardware or IRQ conflict, but I can't really see how that could affect the disk, unless of course it is messing up the Winders write caching. To get the error message you have reported when you are sure that nothing else is attempting to access the file it really does sound like VB has instructed the operating system to close the file, and recorded the fact that it has done so in its own system, but the operating systems has either "forgotten to do it" or simply hasn't got round to doing it yet. Just as a test, have you tried to discover how long it is before the file becomes available again, or if indeed it ever does? You can still retain your "change the file name" stuff (which is keeping your application up and running) and at the same time add a little test in the Timer routine (just for the first file name that fails) to see and record how long it takes (if ever) for that file to become available again. Have you tried turning off disk caching for the whole system. Try it and see. If you are using XP go to My Computer or Explorer and right click the drive and select Properties. Then click the Hardware tab and select the main drive and click Properties again. Then click the Policies tab where you will see and be able to change the write caching setting. Mike Error 70 is "Permission denied". Would't be a file number conflict, as that'll give you an error 55 "File already open". Even if your app has the file open and tries to open it again with a different file number, it'll still give an error 55. Error 70 "Permission denied" probably indicates that the file is either open by another program/process or the lock isn't getting released in time for some strange reason. Again, your app isn't trying to open the file it already has open, or you'd get an error 55. You sure you don't have the file open in an editor or something when this error is thrown? If there isn't a reason not to, try burping it with a DoEvents after the close or before the open. Don't know if it'll make a difference, just a stab in the dark. > This is essentially the code. > 'Find the first available filenumber [quoted text clipped - 18 lines] > > John Fox An afterthought... any antivirus running in the background? Also, how frequent are you writing to the log file? > Error 70 is "Permission denied". Would't be a file number conflict, as > that'll give you an error 55 "File already open". Even if your app has the [quoted text clipped - 32 lines] > > > > John Fox Yes, there will be an anti virus running. Nothing else would be opening the file, the PC is only doing this one task. On average the write is being done once every 2-3 minutes or so over a period of many hours. John > An afterthought... any antivirus running in the background? Also, how > frequent are you writing to the log file? [quoted text clipped - 47 lines] >>> >>>John Fox SignatureAll prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk > Open logfilename For Append Lock Read Write As #fileno > ' saves the time and the data [quoted text clipped - 9 lines] > > John Fox Since it is apparently not doing much good, I would skip the lock completely. I have programs that run overnight and log their activity at comparable rates, and don't seem to have any problem. There is plenty of funny business around file locks without throwing in more. Is the log file by chance on a network drive? Dear Steve, No, it's not on a network drive. I'll try removing the lock, although I think I first wrote it without one. John >>Open logfilename For Append Lock Read Write As #fileno >>' saves the time and the data [quoted text clipped - 24 lines] > funny business around file locks without throwing in more. Is the log > file by chance on a network drive? SignatureAll prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk >Dear Steve, > >No, it's not on a network drive. >I'll try removing the lock, although I think I first wrote it without one. I do not think it is the Lock I think you have something funny going on, where two of your 'strands of execution' are attacking the same file at the same time. Although it is just possible that a Virus checker is peeking at the contents of the file. The Virus checker is worth a thought. It may be worth disabling it for a while. John Fox >>Dear Steve, >> [quoted text clipped - 8 lines] > Although it is just possible that a Virus checker is peeking at the > contents of the file. SignatureAll prices quoted are in UK pounds and do not include any taxes. ****************************************************************** Alta Bioscience Email: altabios@bham.ac.uk The University of Birmingham Phone: +44 (0) 121 414 5450 Edgbaston, Birmingham Fax: +44 (0) 121 414 3376 B15 2TT, UK URL: www.altabioscience.bham.ac.uk |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.