Why there is a limit of 65,536 bytes when writing to file?
Kathy
I have noticed my log file stopped being updated after the log
(text file) reached 65,536 bytes.
I store data into log using this code:
============
FileNum = FreeFile
Open lname For Append As FileNum
Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
Close FileNum
==========
What is causing that limit and how to overcome it?
Thanks,
Kathy
Michael Williams
news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
> Hello, I have noticed my log file stopped being updated
> after the log (text file) reached 65,536 bytes.
> I store data into log using this code:
> FileNum = FreeFile
> Open lname For Append As FileNum
> Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
> Close FileNum
> What is causing that limit and how to overcome it?
That's only a fraction of your code. Where is the rest of it? Where are your
declarations, etc? Where are you getting the data from? And have we been
through almost exactly this question just a few days ago with someone else?
Mike
Nobody
news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
The limit is 2GB. Excel has a limit of 65536 lines, not bytes.
Kathy
What other code can be relevant to that problem?
lname, slog and Record are just strings
lname is the file's name and
slog and Record contain just few text words.
There is not other code writing to that file.
Kathy
"Michael Williams" <Mi...@WhiskyAndCoke.com> wrote in message
news:eYuPIi0p...@TK2MSFTNGP06.phx.gbl...
Karl E. Peterson
> This is just the code which writes to the file periodically.
> What other code can be relevant to that problem?
That's what Michael was wondering about, yes.
> lname, slog and Record are just strings
> lname is the file's name and
> slog and Record contain just few text words.
> There is not other code writing to that file.
That may all be true, but it doesn't lead us any closer to your problem.
>> "Kathy" <Kathy@kathy> wrote in message
>> news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
>>
>>> Hello, I have noticed my log file stopped being updated
>>> after the log (text file) reached 65,536 bytes.
>>> I store data into log using this code:
>>> FileNum = FreeFile
>>> Open lname For Append As FileNum
>>> Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
>>> Close FileNum
>>> What is causing that limit and how to overcome it?
The limit is, I'm sorry to say, strictly in your imagination. If you need to
convince yourself of that, try running this code:
Public Sub Main()
Dim BigBuffer As String
BigBuffer = String$(16 * 1024, "A")
Do
Open "c:\temp\temp.txt" For Append As #1
Print #1, BigBuffer
Debug.Print LOF(1)
Close #1
Loop
End Sub
You'll see there is no such limit on the technique you presented. But, contrary to
what you posted, I'm providing the complete application here. You can start a new
project, put this code in a module, and then type "main" and hit Enter in the
Immediate window (or set the startup to Sub Main and press F5).
No, the problem is the failure here to imagine what else might be causing the
problem you're observing. I'm not even convinced you've adequately observed the
problem because "stopped being updated" is pretty darn information free as problem
descriptions go.
--
.NET: It's About Trust!
http://vfred.mvps.org
Randem
with the same exact code.
--
Randem Systems
Your Installation Specialist
The Top Inno Setup Script Generator
http://www.randem.com/innoscript.html
Disk Read Error Press Ctl+Alt+Del to Restart
http://www.randem.com/discus/messages/9402/9406.html?1236319938
"Kathy" <Kathy@kathy> wrote in message
news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
Karl E. Peterson
> Is this a homework assignment? Someone else asked the same exact question...
> with the same exact code.
Wow, I hadn't noticed. Too bad CrownMan posted from the web interface. Whaddaya
bet they're "coworkers"?
MM
wrote:
>That may all be true, but it doesn't lead us any closer to your problem.
>The limit is, I'm sorry to say, strictly in your imagination. If you need to
>convince yourself of that, try running this code:
>You'll see there is no such limit on the technique you presented. But, contrary to
>what you posted, I'm providing the complete application here. You can start a new
>project, put this code in a module, and then type "main" and hit Enter in the
>Immediate window (or set the startup to Sub Main and press F5).
>No, the problem is the failure here to imagine what else might be causing the
>problem you're observing. I'm not even convinced you've adequately observed the
>problem because "stopped being updated" is pretty darn information free as problem
>descriptions go.
Boy, did someone get out of the wrong side of the bed yesterday
morning! Why not put the poor girl in the stocks and throw cabbages at
her already?
;(
Note that not everyone is as clever as you, nor even me!
MM
Michael Cole
<news:qp61s41c1qlbv8las...@4ax.com>
> Boy, did someone get out of the wrong side of the bed yesterday
> morning! Why not put the poor girl in the stocks and throw cabbages at
> her already?
Read the "VB App fails when log reaches 65536" thread above, particularly
the last post in that thread where the OP (presumably a co-worker of this
poor girl), explains that,
> Get this: the VB.exe tool/app would fail
> after many hours of processing and the person running the tool (which
> was not me at the time), actually took the log and copy/pasted into
> Excell to try to sort it out, or whatever. She then, observed that
> Excell produced the error that I, in turn, posted here. I wasn't
> informed about this, spent hours talking to the DBA's, Sys Admins,
> trying to get some logs; some hint, somewhere. None were
> found....until finally, the tool failed again.
I assume that the "she" refers to this OP...
Methinks that in this company, there is a failure to communicate...
--
Regards
Michael Cole
Michael Williams
> This is just the code which writes to the file periodically.
> What other code can be relevant to that problem?
Well obviously something else is relevant to your problem because nothing in
the code you posted will break at the limit you have mentioned, at least not
if you are using Classic Visual Basic (VB6 and previous versions) which is
what this group deals with. That's why we need more details.
Mike
MM
wrote:
There is, sadly, in most companies. I worked from 1961 till 2001 and I
never managed to disprove the rule for more than a week.
MM
Kathy
Here is what I tried:
I step by step through that code.
1.
No error is generated
2.
As soon as I do:
Close #FileNum
I check the log file. There is NOT new entry included.
Now:
3
I remove the last few lines from the log file.
4.
Step again through the same code.
5.
As soon as I do:
Close #FileNum
I check the log file. The new entry is in there.
Does it convince anybody that it is ONLY that part of code and that
particular log file in question?
You are all men here, and until now I though men can think logically.
I am having some doubts now.
To answer someone else in this thread. No, it is NOT a school project and it
has nothing to do with the other thread , describing *same* problem.
Please someone tell me how to debug this problem.
Thanks,
Kathy
"Michael Williams" <Mi...@WhiskyAndCoke.com> wrote in message
news:egR0zs6p...@TK2MSFTNGP06.phx.gbl...
Kevin Provance
"Kathy" <Kathy@kathy> wrote in message
| You are all men here, and until now I though men can think logically.
| I am having some doubts now.
Psh. Since you want to go down that roead...it's code written by a woman,
no wonder it isn't working.
dpb
...
> I check the log file. ...
How, specifically, did you do this "check"?
--
Jeff Johnson
>
> Here is what I tried:
> I step by step through that code.
> 1.
> No error is generated
> 2.
> As soon as I do:
> Close #FileNum
> I check the log file. There is NOT new entry included.
> Now:
> 3
> I remove the last few lines from the log file.
> 4.
> Step again through the same code.
> 5.
> As soon as I do:
> Close #FileNum
> I check the log file. The new entry is in there.
Exactly HOW do you check the log file? What program do you use to read it?
Excel? If that's the case then it has been mentioned in BOTH threads that no
version of Excel except 2007 can display more than 65,636 ROWS. Since your
code is using the Print # statement, a CR/LF is getting inserted at the end
of each line, and therefore Excel will see each log entry as a row.
If you are indeed opening this file in Excel, try something else. As long as
you're using a modern Windows OS (not 95 or 98, for example), plain old
Notepad should be able to handle large files. Open your log with that and
see if your "missing" records suddenly appear.
Nobody
VB5/6 supports more than 65536 bytes. Try the following code in a new
project. In my case, I could append without limit(No 2 or 4GB limit) on NTFS
under XP. I appended till the file size became 5GB. When "For Binary" is
used, the limit is 2 GB, however, not sure about "For Output". This is the
reason why others think that the problem is somewhere else...
Option Explicit
Private Sub Form_Load()
Dim i As Long
Dim f As Long
Dim BigBuffer As String
BigBuffer = String$(1024, "A")
f = FreeFile
Open "c:\temp\temp.txt" For Append As f
For i = 1 To 10000
Print #f, BigBuffer
Next
Close f
End Sub
This will create about 10 MB file, so whatever you are experiencing is not a
limitation of VB5/6.
What type of drive are you writing to? Local? Network? USB?
Do you have an error handler in the routine that writes the log? If so,
could you post what type? GoTo or Resume Next?
"Record" declaration is not shown, so we can't tell if it's type String or
an Object that maybe throwing errors for some reason.
Jeff Johnson
news:ew3ZKC$pJHA...@TK2MSFTNGP04.phx.gbl...
> no version of Excel except 2007 can display more than 65,636 ROWS.
Damn typos. Of course I meant 65,536.
Nobody
wrote in message news:O8yaE9%23pJH...@TK2MSFTNGP05.phx.gbl...
No wonder Bush got elected twice.
Al Reid
What tool are you using to inspect the log file? Perhaps it has a limit.
Try this. Start a new project and put 2 command buttons on the form and
past in the following code.
Private Sub Command1_Click()
Me.MousePointer = vbHourglass
Dim FileNem As Integer
Dim i As Long
FileNum = FreeFile
Open "C:\TestLog.txt" For Append As FileNum
For i = 1 To 2 ^ 17 - 1
Print #FileNum, "0123456789"
Next
Close FileNum
Me.MousePointer = vbDefault
End Sub
Private Sub Command2_Click()
Me.MousePointer = vbHourglass
Dim FileNem As Integer
Dim s As String
Dim i As Long
FileNum = FreeFile
Open "C:\TestLog.txt" For Input As FileNum
Do Until EOF(FileNum)
Line Input #FileNum, s
i = i + 1
Loop
Close FileNum
MsgBox i
Me.MousePointer = vbDefault
End Sub
What do you see?
--
Al Reid
Karl E. Peterson
A sad winkie? Hmmmm.
At any rate, it wasn't meant to be as harsh as you took it. But really. You are,
purportedly, a developer. Have you, as a developer, ever used the phrase "stopped
being updated" and expected *anyone* to take that as the final word in accurately
describing a problem? Or was it merely the prelude to a finer description, assuming
the person you were talking to indicated some level of interest at this point?
Mike William's response was on point. Either there's more code to the problem, or
the analysis of the problem is seriously flawed. The language doesn't lend itself
to the conclusion offered. If that truly is all the code that's involved, then the
observation/conclusion is coming at us from left-field. Not an assumption we'd make
nonchalantly about someone we don't know, is it? So, rightly, he didn't. Yet, she
insisted the code was all there. What's left at that point? Note, my response is
*still* trying very hard to be charitable!
> Note that not everyone is as clever as you, nor even me!
Well, even given the absolute truth in that statement, I don't see it as having
relevance here. <g>
Karl E. Peterson
> You are all men here, and until now I though men can think logically.
> I am having some doubts now.
Typical. <g>
But let's test *your* logic, shall we...
> 2.
> As soon as I do:
> Close #FileNum
> I check the log file. There is NOT new entry included.
What *logical* methods are you using to check your log file? Details matter.
Would you *logically* expect a tool with a 64k limit to show the new entry?
MikeB
"Kathy" <Kathy@kathy> wrote in message
>
> You are all men here, and until now I though men can think logically.
> I am having some doubts now.
Forget whatever you are using to visually look at the file.
Is the file increasing in physical size via Windows Explorer after each
update?
That should give you a clue whether your inspection method is flawed.
Larry Serflaten
"Kathy" <Kathy@kathy> wrote
> Does it convince anybody that it is ONLY that part of code and that
> particular log file in question?
Not quite yet, as others pointed out, the method used to examine the
contents has not been included.
As with most problems, it would help a great deal if you could
reproduce the error in a short demo and post that to the group
so that others can see the error on their own system. That helps
to eliminate any situations that are particular to your own setup,
plus gives the actual code used in place of any worded descriptions.
For example, on a new form with an added command button,
the folllowing code helps to prove there is no such 64K limit
to appending files. Paste in the code below, change the TestFile
string to work on your own system and run the program. Pressing
the button several times will bring the file size over 64K....
Now, can you post a short demo that reproduces your problem?
LFS
Option Explicit
Private Const TestFile = "D:\temp\testfile.txt"
Private Sub Command1_Click()
Dim ff&, txt$
ff = FreeFile
Debug.Print "- - -"
On Error GoTo Handler
Open TestFile For Append As ff
Debug.Print "Start size:", LOF(ff)
Print #ff, String(20, (Int(Timer) And 31) + 65)
Close ff
Open TestFile For Input As ff
Debug.Print "New size:", LOF(ff)
txt = Input(LOF(ff), ff)
Close ff
Debug.Print "Last 60:"
Debug.Print Right(txt, 66)
Handler:
If Err.Number > 0 Then
Debug.Print Err.Description
Close
End If
End Sub
Private Sub Form_Load()
Open TestFile For Output As 1
Print #1, String(65500, "X")
Close #1
End Sub
Kathy
And it is a plain, text file.
Thank you,
Kathy
"Jeff Johnson" <i....@enough.spam> wrote in message
news:ew3ZKC$pJHA...@TK2MSFTNGP04.phx.gbl...
Kathy
Thank you,
Kathy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:exM8Nz$pJHA...@TK2MSFTNGP03.phx.gbl...
Kathy
I use Windows Explorer, Right click on file and select Properties to check
the file length
Thanks,
Kathy
"MikeB" <baue...@hotmail.com> wrote in message
news:um8huWAq...@TK2MSFTNGP03.phx.gbl...
Karl E. Peterson
>>> I check the log file. There is NOT new entry included.
>>
>> What *logical* methods are you using to check your log file? Details
>> matter.
>
The "logic" there isn't obvious to me, but WTH do I know? <shrug>
Anyway, what does the following test tell you?
Public Sub Test()
Dim fn As String
Dim i As Long
Dim buffer As String
fn = Environ("TMP") & "\LotsaLines.txt"
For i = 1 To 100000
buffer = buffer & Format$(i, "000000") & vbCrLf
If i Mod 100 = 0 Then
Open fn For Append As #1
Print #1, buffer
Close #1
buffer = ""
End If
Next i
Shell "notepad " & fn
Debug.Print FileLen(fn); "bytes"
End Sub
When I paste that into a module, then hop over to the Immediate window and type
"test<Enter>", I see this:
test
1504001 bytes
And, of course, Notepad pops up with a file that shows 100000 lines of text. Quite
clearly more than 64k bytes.
There's something you're failing to tell us. Please follow Larry's advice, and
provide an easily reproducible case.
Eduardo
What do you mean with "Yes"?
1) Is the file increasing size (even when you cannot see the line added)?
2) "Yes", you checked with Windows explorer, but the file size doesn't
change?
"Kathy" <Kathy@kathy> escribió en el mensaje
news:OnXHDGBq...@TK2MSFTNGP03.phx.gbl...
> Yes,
> I use Windows Explorer, Right click on file and select Properties to check
> the file length
> Thanks,
> Kathy
> "MikeB" <baue...@hotmail.com> wrote in message
> news:um8huWAq...@TK2MSFTNGP03.phx.gbl...
>> Is the file increasing in physical size via Windows Explorer after each
>> update?
DanS
@TK2MSFTNGP02.phx.gbl:
> "Kathy" <Kathy@kathy> wrote in message
> news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
>> Hello,
>> I have noticed my log file stopped being updated after the log
>> (text file) reached 65,536 bytes.
>> I store data into log using this code:
>> ============
>> FileNum = FreeFile
>> Open lname For Append As FileNum
>> Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
>> Close FileNum
>> ==========
>> What is causing that limit and how to overcome it?
>> Thanks,
>> Kathy
>
> The limit is 2GB. Excel has a limit of 65536 lines, not bytes.
Just a note, Excel in Office 2007 is no longer limited to 65,536 lines.
Michael Williams
> Notepad. Just, old plain Windows Notepad and the
> Windows is XP. Thank you, Kathy
Look, Kathy. There are things you are not telling us. For example, you are
not telling us the length of the two strings you are writing (slog and
Mid(Record, 3)), although we can guess what slog is and in any case those
two, regardless of their length, are unlikely to cause a failure at exactly
65536 writes. If you are using VB6 then there is *nothing* in the following
code, the only code you have shown us so far, that would cause a failure at
65536 writes:
FileNum = FreeFile
Open lname For Append As FileNum
Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
Close FileNum
So something else, perhaps something in the code you are using which calls
the above function, is causing your problem, or the problem perhaps does not
actually exist (if you are interpreting the result incorreectly for
example). Why won't you show it to us the code that calls the short example
you have posted? Also, it would help if you told us exactly how you are
checking the result and exactly what (if any) error messages you are getting
and exactly what else you are using besides the code you have shown us.
Try the various code examples that have been posted by Karl and others,
which should prove to you that there are no problems whatsoever with VB6
writing more than 65536 lines to a file using code similar to your own.
There are obviously some problems at your end, but they are /not/ problems
with the code you have posted and so they must be problems with something
you haven't. Naturally you want to find your problem so that you can solve
it, but you are never going to find it if you insist on looking in the wrong
place.
Mike
DanS
> Hello,
> I have noticed my log file stopped being updated after the log
> (text file) reached 65,536 bytes.
> I store data into log using this code:
> ============
> FileNum = FreeFile
> Open lname For Append As FileNum
> Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
> Close FileNum
> ==========
> What is causing that limit and how to overcome it?
> Thanks,
> Kathy
I didn't see a resolution to this yet, so here's my 2ข.....
No, nevermind. I just reread your post and the showstopper was the file
byte ize, not the number of rows in the log.
As others have said, that code should work fine for big files.
(If it was for the number of entries, I was thinking your variable 'slog'
was a log number entry, and you had it declared as an Integer, which would
explain why the number of entires would stop at that point.)
Of course, you'd need to have an 'On Error Resume Next' somewhere in your
code and then you may not even see the error. Just for sh*ts & giggles, if
you do have any On Error Resume Next's in your code, rem them out and try
again.
MM
wrote:
>MM wrote:
>> On Tue, 17 Mar 2009 15:27:50 -0700, "Karl E. Peterson" <ka...@mvps.org>
>> wrote:
>>
>>>That may all be true, but it doesn't lead us any closer to your problem.
>>
>>>The limit is, I'm sorry to say, strictly in your imagination. If you need to
>>>convince yourself of that, try running this code:
>>
>>>You'll see there is no such limit on the technique you presented. But, contrary
>>>to
>>>what you posted, I'm providing the complete application here. You can start a new
>>>project, put this code in a module, and then type "main" and hit Enter in the
>>>Immediate window (or set the startup to Sub Main and press F5).
>>
>>>No, the problem is the failure here to imagine what else might be causing the
>>>problem you're observing. I'm not even convinced you've adequately observed the
>>>problem because "stopped being updated" is pretty darn information free as problem
>>>descriptions go.
>>
>> Boy, did someone get out of the wrong side of the bed yesterday
>> morning! Why not put the poor girl in the stocks and throw cabbages at
>> her already?
>>
>> ;(
>
>A sad winkie? Hmmmm.
>
>At any rate, it wasn't meant to be as harsh as you took it.
I'm English. We are a reserved race. Look at the way we just let you
have America! All that fuss over a few boxes of tea when we had the
whole of India to plunder, dearie me.
> But really. You are,
>purportedly, a developer.
Not any more! I hung up my coding clogs professionally in 2001. Since
then I have got up late, had a leisurely bath, ate some grits (not
really, but it sounds kinda Kerouac/Steinbeck-like that I know y'all
love), and occasionally switched on the jolly old PCs. I keep my brain
in gear with VB6. But for Bill's baby I'd be suffering from
early-onset dementia already. (Thanks, Bill!)
> Have you, as a developer, ever used the phrase "stopped
>being updated" and expected *anyone* to take that as the final word in accurately
>describing a problem? Or was it merely the prelude to a finer description, assuming
>the person you were talking to indicated some level of interest at this point?
All I'm sayin', is, you don't need to be quite so abrupt with the puir
wee lassie. She could be your daughter! Treat a lady right, is what I
say!
>Mike William's response was on point. Either there's more code to the problem, or
>the analysis of the problem is seriously flawed. The language doesn't lend itself
>to the conclusion offered. If that truly is all the code that's involved, then the
>observation/conclusion is coming at us from left-field. Not an assumption we'd make
>nonchalantly about someone we don't know, is it? So, rightly, he didn't. Yet, she
>insisted the code was all there. What's left at that point? Note, my response is
>*still* trying very hard to be charitable!
Gawd! If that was charitable, I'd hate to see you all riled up!
>> Note that not everyone is as clever as you, nor even me!
>
>Well, even given the absolute truth in that statement, I don't see it as having
>relevance here. <g>
Thanks for playing!
MM
Henning
chance the first char in a line could be that code?
/Henning
"Kathy" <Kathy@kathy> skrev i meddelandet
news:OnXHDGBq...@TK2MSFTNGP03.phx.gbl...
Jeff Johnson
news:Xns9BD2C1B70FB83th...@85.214.105.209...
> (If it was for the number of entries, I was thinking your variable 'slog'
> was a log number entry, and you had it declared as an Integer, which would
> explain why the number of entires would stop at that point.)
No, we've already been through that. 65,536 would be an overflow for an
UNSIGNED integer, but VB doesn't support that. Its integer will barf at
32,768....
Kathy
I am really curious, why none of the big shots (all males of course) did not
suggest that?
Am I alone stepping on the mine field?
I traced that the problem appears only when FreeFile returns 2.
I know what does it mean.
I have checked my code multiple times and I cannot find anywhere where the
opened file is not being closed.
But, besides that.
Can you guys please explain the mechanism how another opened file can create
that problem?
How that can be related?
As far as I understand, FreeFile returns the NEXT file number available for
use by the Open statement.
So, assuming that there is another file opened, how that fact can limit the
size of the next file to be opened?
I entertain all your responses,
Thanks,
Kathy
"Kathy" <Kathy@kathy> wrote in message
news:%238zJUD0...@TK2MSFTNGP04.phx.gbl...
Jeff Johnson
>I think I have found the source of the problem.
> I am really curious, why none of the big shots (all males of course) did
> not suggest that?
> Am I alone stepping on the mine field?
> I traced that the problem appears only when FreeFile returns 2.
> I know what does it mean.
> I have checked my code multiple times and I cannot find anywhere where the
> opened file is not being closed.
> But, besides that.
> Can you guys please explain the mechanism how another opened file can
> create that problem?
> How that can be related?
> As far as I understand, FreeFile returns the NEXT file number available
> for use by the Open statement.
> So, assuming that there is another file opened, how that fact can limit
> the size of the next file to be opened?
> I entertain all your responses,
Here's my response: you're being an ass. I don't know if you're a troll or
you're just a nasty person.
The people in this group have been using VB for years. We've seen lots of
problems, both in our own experience and as questions posted here. A lot of
people are CONVINCED that they know the cause of their problem and doggedly
search for a solution to that particular cause, only to ultimately find out
that there was a totally different reason altogether.
It has been explained to you several times that the file size limit you
believe you are experiencing is NOT any kind of limit in VB. Code has been
posted to allow you to prove this fact for yourself.
Once again you have come in and told us that you have experienced "the
problem," and once again you think you've found the cause. You have not. You
have managed to whittle the issue down to a certain set of variables
(FreeFile returning 2), and for that I congratulate you. Every little bit of
info helps. But it's only a little bit. You still have not given us enough
information to reproduce this problem for ourselves. What you need to do is
make a SECOND project. It should be an extremely tiny project, with only
enough code to reproduce the problem. You should be able to do it all in Sub
Main. Once you can reproduce it, post the code here so we can all try it. If
you can't reproduce it, then clearly THERE'S MORE GOING ON THAN YOU THINK.
Here's a little rant about clarity: As a programmer, you don't sit down at
your computer, open up VB, and type "Do some stuff with that variable. And
then do some other stuff with the other variable." No. You must be EXPLICIT
and EXACTING when writing code. I don't understand why programmers can't
apply that explicit and exacting mindset to posts they make in this group.
The moment they're not typing into a form or a module they suddenly think
it's okay to be vague. Why? Treat us like we're computers: we can't give
proper output until we have COMPLETE input.
dpb
...
> I traced that the problem appears only when FreeFile returns 2.
> I know what does it mean.
> I have checked my code multiple times and I cannot find anywhere where the
> opened file is not being closed.
Ah...this was here not long ago, too. I forget if it was the same
poster as the other one w/ this specific problem as well but surely
seems as though it was.
The answer is there's either a sneak execution path you've not
identified or an error handler or similar cause for a mismatched set of
OPENs and CLOSEs. "Similar causes" could include "creative" things
going on in third-part controls, direct API calls, etc., etc., etc., ...
Just like the 64K magic number isn't, Freefile _WILL_ return the next
available free file handle beginning with 1. If it doesn't, then #1 is
still in use. Period.
--
Kathy
"Jeff Johnson" <i....@enough.spam> wrote in message
Kathy
random...@gmail.com
> I traced that the problem appears only when FreeFile returns 2.
> I know what does it mean.
> I have checked my code multiple times and I cannot find anywhere where the
> opened file is not being closed.
You are claiming two things that I have never seen, or even heard of:
Close not closing a file handle, and two file handles colluding to
limit the amount of data written to one file. Can you show some code
that demostrates these problem?
If you can't, you're asking a group of people to use psychic debugging
powers, and really all you expect is a "you have a bug in your code"
response.
> I am really curious, why none of the big shots (all males of course) did not
> suggest that?
Do you honestly expect nice responses when you include sexist little
pot-shots like this?
dpb
...
> You are claiming two things that I have never seen, or even heard of:
> Close not closing a file handle, and two file handles colluding to
> limit the amount of data written to one file. Can you show some code
> that demostrates these problem?
There was another thread just a few days ago where the same
problem/symptoms were posted--there, at the IDE the OP could close the
open handles but also claimed no discernible paths by which an
OPEN/CLOSE pair didn't match. No firm resolution within that thread but
iirc it evolved into the "overflow" discussion which then morphed from
that OP to our bitter friend, Kathy.
--
Henning
error condition dissapears. If so, I bet you have an ErrorHandler jumping
back to the wrong place.
/Henning
"Kathy" <Kathy@kathy> skrev i meddelandet
news:ezOhCnLq...@TK2MSFTNGP06.phx.gbl...
Kevin Provance
"Kathy" <Kathy@kathy> wrote in message
| Wow!
| Kathy
Yeah, you just got bitch slapped, which has been a long time coming.
Karl E. Peterson
>> Have you, as a developer, ever used the phrase "stopped
>>being updated" and expected *anyone* to take that as the final word in accurately
>>describing a problem? Or was it merely the prelude to a finer description,
>>assuming the person you were talking to indicated some level of interest at this
>>point?
>
> All I'm sayin', is, you don't need to be quite so abrupt with the puir
> wee lassie. She could be your daughter! Treat a lady right, is what I
> say!
Well, see, one of my upcoming columns is titled "Prisoner of Geography" or something
like that. Here, in the US, it's all about Equal Opportunity. I accept mental
laziness no more in women than do I in men. The ones worth knowing (okay, *now*
we're getting subjective <g>) tend to respect that. And really, that's one of the
things that got me so interested in online places like this in the first place.
People here are judged *solely* by the quality, or lack thereof, of their thoughts.
Kim could be Ken for all I know. Doesn't matter.
>>Mike William's response was on point. Either there's more code to the problem, or
>>the analysis of the problem is seriously flawed. The language doesn't lend itself
>>to the conclusion offered. If that truly is all the code that's involved, then
>>the
>>observation/conclusion is coming at us from left-field. Not an assumption we'd
>>make nonchalantly about someone we don't know, is it? So, rightly, he didn't.
>>Yet, she insisted the code was all there. What's left at that point? Note, my
>>response is *still* trying very hard to be charitable!
>
> Gawd! If that was charitable, I'd hate to see you all riled up!
Heh. Yes, you would. :-)
Karl E. Peterson
> Wow!
> Kathy
Hey MM, this post of Jeff's is *verging* on non-charitable! ;-)
Karl E. Peterson
> I think I have found the source of the problem.
LOL!
> I am really curious, why none of the big shots (all males of course) did not
> suggest that?
I actually think you're intimately familiar with the source of your problem!
Kevin Provance
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:eolfUBOq...@TK2MSFTNGP06.phx.gbl...
| I actually think you're intimately familiar with the source of your
problem!
Dead batteries in the vibrator? <eg>
Dan
> "Kathy" <Kathy@kathy> wrote in message
>
>
> > Hello, I have noticed my log file stopped being updated
> > after the log (text file) reached 65,536 bytes.
> > I store data into log using this code:
> > Open lname For Append As FileNum
> > Print #FileNum, """" & slog & """" & "," & Mid(Record, 3)
> > Close FileNum
>
> declarations, etc? Where are you getting the data from? And have we been
> through almost exactly this question just a few days ago with someone else?
>
> Mike
Hmmmm. I just checked out this thread ( 1st time looking at the
mail from this group ). Kathy... Mike's response to you is RIGHT ON
TARGET. Don't dismiss what he asks of you so easily. A lot of
beginners (using a lot of different languages) make the same mistake
which you are now making.... which is not posting enough of your code
(including the declarations). I've seen it time and time again.
Mike has been at this a long time (I've seen him in the newsgroups
from years back). Post more of your code and I'm sure he (and
others) can tell you exactly what you are doing wrong.
Side note: Go find something better than Notepad to use with text
files. There are LOTS of freebies out there that are all way, way,
WAY better and easier and more intuitive to use than Notepad.
Especially, if you ever mess with large files. Notepad will choke on
itself if you attempt to use it with large files.
Bill McCarthy
"Kathy" <Kathy@kathy> wrote in message
news:ezOhCnLq...@TK2MSFTNGP06.phx.gbl...
<snip>
> I traced that the problem appears only when FreeFile returns 2.
Look at your error handling to ensure that you are closing the file handle
even when an error happens whilst logging. It's a common mistake that
people fail to have error handling in their error logging routines.
Jeff Johnson
were all correct about the Excel thing and slunk away quietly?
Nobody
> So, folks, it's been about a week. What's the consensus? She realized we
> were all correct about the Excel thing and slunk away quietly?
Probably mixing #FNum and #2, or using Seek statement to go backward,
limiting file size.
Karl E. Peterson
> "Jeff Johnson" <i....@enough.spam> wrote ...
>> So, folks, it's been about a week. What's the consensus? She realized we
>> were all correct about the Excel thing and slunk away quietly?
>
> Probably mixing #FNum and #2, or using Seek statement to go backward,
> limiting file size.
I still don't get the 64k *bytes* thing, though. WTH?
Al Reid
news:OW2pN5Yr...@TK2MSFTNGP05.phx.gbl...
> were all correct about the Excel thing and slunk away quietly?
I think she's looking for an all female NG to ask in so she can get some
logical advice :o)
--
Al Reid
Rick Raisley
stereotyping her, and then she perpetuates the stereotype. ;-)
--
Regards,
Rick Raisley
heavymetal-A-T-bellsouth-D-O-T-net
"Jeff Johnson" <i....@enough.spam> wrote in message
news:OW2pN5Yr...@TK2MSFTNGP05.phx.gbl...