How many ActiveX controls can I have? Stack overflow problems...

[Jim]

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[TC]

> My question is, would I have a stack overflow if I split the above

mentioned form into three separate forms, yet had them all loaded at
the same time?
Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m... I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[Mike Storr]

On 23 Feb 2004 11:53:24 -0800, Jim wrote:

From MS KB article 145799

Stacks are reserved memory that programs use to process hardware events. A
stack overflow occurs when there is not enough space in memory to run the
hardware interrupt routines....

--------------------------------------------------------------------------------------------
I really don't see how you could be creating one of these errors with
ActiveX controls. If anything, you'd hit an Out of Memory, or Page Fault
first.

--
Mike Storr
www.veraccess.com

[Jim]

Thanks very much for your reply. I clearly don't understand stacks.
Can someone explain how they work with regards Access? I've just spent
several hours trawling the web, and popped down to Waterstones by
Piccadilly Circus (apparently the largest bookstore in Europe) and
found absolutely nothing useful.

Thanks
Jim

"TC" <[e-mail]> wrote in message news:<40**********@news.chariot.net.au>...

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time?

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[Brendan Reynolds]

I doubt you'll ever get any very specific answer to this question, Jim, but
in general terms, that sure sounds like an impractically complex form to me.
This opinion is not based on any deep understanding of the internal workings
of Access, VBA, or the stack, but purely on personal, subjective experience.
But for whatever it might be worth, I would never, in my wildest dreams,
contemplate attempting to create a form as complex as that.

--
Brendan Reynolds

"Jim" <js*****@hotmail.com> wrote in message
news:5c**************************@posting.google.c om...

Thanks very much for your reply. I clearly don't understand stacks.
Can someone explain how they work with regards Access? I've just spent
several hours trawling the web, and popped down to Waterstones by
Piccadilly Circus (apparently the largest bookstore in Europe) and
found absolutely nothing useful.

Thanks
Jim

"TC" <[e-mail]> wrote in message

news:<40**********@news.chariot.net.au>...

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time?

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly say whether splitting it up, would fix the problem. Maybe it would - maybe it wouldn't! AFAIK there is no magic forumla where someone could plug in the number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[DFS]

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).
Jim,

As the others have noted, your problems aren't stack overflows. Actually,
you don't specify exactly what kind of problems you are having. Your form
isn't very complex, yet, but it appears to be heading that way. You might
lighten it up a bit by moving some things to another form, and moving most
of the code to a public module.

I've also built large, complex main forms, with two nested tab controls, 15
or so subforms, 100 text boxes, 2500 lines of code, 20 click buttons, linked
images, 10 option groups, 20 small-recordsource comboboxes, etc. and not
had any stability problems. But I eventually got a little worried, and
lightened it up. If that one form gets corrupted, you might have a
difficult time replicating it.
Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[Jim]

A few more details on the below problem:

The database works perfectly well on my PC. It will not work on other
PCs (all PCs in my office use Win2K and Office2K.

The error used to be that Access would simply crash (MS Access has
generated errors) and closes. After I installed some patches for
Win2K, the error then became 'Run time error 28 - out of stack space.'
Upon receiving this error, Access either crashes or closes down. I
can't see any other differences between the installations on each PC.

I'm baffled as to why my PC works, but others don't. Any ideas would
really be appreciated.

Also, as per my other reply to your message, any help on what stack
overflows mean etc would really help as I am by no means an expert and
have been unable to find any decent literature on the subject..

Thanks
Jim
"TC" <[e-mail]> wrote in message news:<40**********@news.chariot.net.au>...

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time?

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[Matthew Sullivan]

That's a strange definition of "stack". Methinks it is valid only
within the context of a certain type of problem (not the problem we've
got here).

A stack is simply an area of physical memory that is used for dynamic
memory allocation. My hunch is that in VBA that applies to pretty
much everything we have programming control over, except global and
static variables (and constants, which probably occupy no memory at
all).

On Mon, 23 Feb 2004 22:48:14 -0500, Mike Storr <st******@sympatico.ca>
wrote:

On 23 Feb 2004 11:53:24 -0800, Jim wrote:

From MS KB article 145799

Stacks are reserved memory that programs use to process hardware events. A
stack overflow occurs when there is not enough space in memory to run the
hardware interrupt routines....

--------------------------------------------------------------------------------------------
I really don't see how you could be creating one of these errors with
ActiveX controls. If anything, you'd hit an Out of Memory, or Page Fault
first.

[test]

Jim, I agree with Brendan. You need to be concerned with the size of stack
storage, only when you are writing in a low level language like assembly
code. Writing in Access VBA is waaaaaaaaaaaaaay above that level. There are
people in this ng who have written hundreds of thousands of lines of Access
VBA code. None of them would have been thinking about stack size, at any
stage, IMHO.

I've just seen your other reply providing more details, so I'll switch to
that one now :-)

Cheers,
TC
"Brendan Reynolds" <br******@removethisindigo.ie> wrote in message
news:Ut*****************@news.indigo.ie...

I doubt you'll ever get any very specific answer to this question, Jim, but in general terms, that sure sounds like an impractically complex form to me. This opinion is not based on any deep understanding of the internal workings of Access, VBA, or the stack, but purely on personal, subjective experience. But for whatever it might be worth, I would never, in my wildest dreams,
contemplate attempting to create a form as complex as that.

--
Brendan Reynolds

"Jim" <js*****@hotmail.com> wrote in message
news:5c**************************@posting.google.c om...

Thanks very much for your reply. I clearly don't understand stacks.
Can someone explain how they work with regards Access? I've just spent
several hours trawling the web, and popped down to Waterstones by
Piccadilly Circus (apparently the largest bookstore in Europe) and
found absolutely nothing useful.

Thanks
Jim

"TC" <[e-mail]> wrote in message news:<40**********@news.chariot.net.au>...

> My question is, would I have a stack overflow if I split the above
> mentioned form into three separate forms, yet had them all loaded at
> the same time?

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly say whether splitting it up, would fix the problem. Maybe it would - maybe it wouldn't! AFAIK there is no magic forumla where someone could plug in the

number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...
> I have spent the past few weeks designing a database for my company.
> The problem is I have started running into what I believe are stack
> overflow problems. There are two tab controls on the form (nested),
> three list views, one tree control with up to 30,000 nodes, maybe 15
> comboboxes (half of which have a large recordset as rowsource), 20

or > so buttons and around 30 text boxes (not to mention the images,
> labels, etc and around 1000 lines of VBA behind it all).
>
> Clearly (and as I write this, it becomes more apparent), this is a
> good contender for stack overflow. (Having said that, the old version > of the database I wrote had the tree control and combo boxes, yet
> didn't run into any problems)
>
> My question is, would I have a stack overflow if I split the above
> mentioned form into three separate forms, yet had them all loaded at
> the same time? Would I have to compromise and close each form before
> opening another?
>
> Also, how can I assess how full the stack is, so that I can anticipate > an overflow ahead of time?
>
> Any help greatly appreciated
> Jim

[TC]

I take it that your home PC is also win2k & office2k?

Here's what I'd try.

First, on the off chance there is some curruption in your database: create a
new db & import all the objects from the old db. Then open any code module &
do a "compile & save all" (from the Debug menu, I think; I don't have Access
here to check). Confirm the new db works ok on your home pc.

Then take it to the office pc, & see if it works there. Use exactly the same
sequence of actions, that you use on the home pc. (Eg. double-click the
databsee, run the startup form, select main menu option #123 - whatever.)

If it works, maybe you have solved your problem. If it doesn't, please tell
us exactly what is the sequence of actions involved; that is: "I do this -
it does that - I do the other", etc.

As for the stack overflow: it is possible to get stack overflows by making
certain kinds of programming errors. But if that were the case, the error
would happen at home, as well as the office - >unless< you are taking a
different series of actions in the two locations. That is why it is
important to follow exactly the same sequence of actions, in each location,
when you do more testing.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c**************************@posting.google.c om...

A few more details on the below problem:

The database works perfectly well on my PC. It will not work on other
PCs (all PCs in my office use Win2K and Office2K.

The error used to be that Access would simply crash (MS Access has
generated errors) and closes. After I installed some patches for
Win2K, the error then became 'Run time error 28 - out of stack space.'
Upon receiving this error, Access either crashes or closes down. I
can't see any other differences between the installations on each PC.

I'm baffled as to why my PC works, but others don't. Any ideas would
really be appreciated.

Also, as per my other reply to your message, any help on what stack
overflows mean etc would really help as I am by no means an expert and
have been unable to find any decent literature on the subject..

Thanks
Jim
"TC" <[e-mail]> wrote in message

news:<40**********@news.chariot.net.au>...

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time?

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly say whether splitting it up, would fix the problem. Maybe it would - maybe it wouldn't! AFAIK there is no magic forumla where someone could plug in the number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC

"Jim" <js*****@hotmail.com> wrote in message
news:5c*************************@posting.google.co m...

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim

[Jim]

Thanks for all your comments. I'm beginning to suspect that I don't
have a 'clean' install of either Windows or Office. The form works
fine on my PC, but after a certain amount of usage, I get an 'out of
memory - please close other apps' message, after which the labels and
other form text changes to 10pt fixed-sys font (ie the form starts to
look crappy). Still doesn't work on any other PC that I've tried.

On the stacks issue, I accept your comments that it's not a stack
space problem. I wonder if someone could point me in the direction of
some good reading material where I can learn more about stacks and how
they work in relation to Access.

Again, I really appreciate all your comments. Thanks.
Jim

[Mike Storr]

I believe the article pertains more to the "Overflow" error the original
poster mentioned than what a stack is. I personally have never seen an
overflow error that was not hardware related, just Out of Stack (or Heap)
Space,

"Matthew Sullivan" <Ma**@NoSpam.com> wrote in message
news:n4********************************@4ax.com...

That's a strange definition of "stack". Methinks it is valid only
within the context of a certain type of problem (not the problem we've
got here).

A stack is simply an area of physical memory that is used for dynamic
memory allocation. My hunch is that in VBA that applies to pretty
much everything we have programming control over, except global and
static variables (and constants, which probably occupy no memory at
all).

[Michael \(michka\) Kaplan [MS]]

"Jim" <js*****@hotmail.com> wrote...

I wonder if someone could point me in the direction of
some good reading material where I can learn more about
stacks and how they work in relation to Access.

-------------------------------
Moving away from Access for a moment for the backstory....

The stack is a part of every thread that runs under Windows. When the thread
is created it is given a specific amount of memory space, known as "the
stack" -- usually 1mb but you can set it higher or lower if you need to.
This is the memory that is easiest to use as it is right there. Every time
you call a function, the computer remembers where you are in the stack and
marks it. The local variables like Integers and Longs get allocated right
off the stack, and then when you exit the function, the computer remembers
where it was and basically "forgets" all of the stack after that point, thus
allowing a cheap way to deallocate local memory.

Now stack is very easy, as the above indicates. The problem is that there is
only so much of it -- so you do not want allocate huge buffers on the stack.
And every time you call a new procedure it "pushes more stack" for that
procedure's local variables. This is why a recursive function can lead (in
VBA) to an "Out of stack space" error -- because each call pushes a little
more stack until there would have been none left. VBA is nice though (in C
you would just crash -- its harder to recover from these errors than most
people know how to handle!).

-------------------------------
Getting back to the scenario....

Now, it is *very* unlikely that lots of forms or even a form with lots of
controls would lead to problems with stack space since the controls are not
created from each other -- they have to be separately allocated. You can
have out of memory issues but that is really referring to the heap, not the
stack.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

[Tony Toews]

"Michael \(michka\) Kaplan [MS]" <mi*****@online.microsoft.com> wrote:

Moving away from Access for a moment for the backstory....

Thanks. Always interesting to learn more about what happens behind the scenes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Jim]

Thanks to all who have answered my questions. Your answers have been
extremely useful and I've learnt things that I doubt I'd ever find in books
(and I've tried pretty hard...)

I'll try out some of the suggestions tomorrow and will reply with my hotmail
login (can't use NNTP through the firewall at work for my ISP).

Cheers
Jim

[Matthew Sullivan]

Interesting! Our experiences are exactly opposite: all the stack
problems I've seen were coding-related.

That kind of variety is one of the things that's what makes this group
so cool!

Here's an example of code that blows the stack up:

Private Sub TestStackSpace()
TestStackSpace
End Sub

-Matt
On Wed, 25 Feb 2004 07:53:22 -0500, "Mike Storr"
<no****@somewhere.con> wrote:

I believe the article pertains more to the "Overflow" error the original
poster mentioned than what a stack is. I personally have never seen an
overflow error that was not hardware related, just Out of Stack (or Heap)
Space,

"Matthew Sullivan" <Ma**@NoSpam.com> wrote in message
news:n4********************************@4ax.com.. .

That's a strange definition of "stack". Methinks it is valid only
within the context of a certain type of problem (not the problem we've
got here).

A stack is simply an area of physical memory that is used for dynamic
memory allocation. My hunch is that in VBA that applies to pretty
much everything we have programming control over, except global and
static variables (and constants, which probably occupy no memory at
all).

[Mike Storr]

On Wed, 25 Feb 2004 17:36:23 -0600, Matthew Sullivan wrote:

Private Sub TestStackSpace()
TestStackSpace
End Sub

Your example does exactly as I had mentioned. Runtime Error 28 - Out of
Stack Space, not the same as an Overflow.
--
Mike Storr
www.veraccess.com

[Matthew Sullivan]

OK, I've got my head out of my *ss now....

When the original poster said "stack overflow" I assumed (apparently
incorrectly) that he was mixing up his terms and actually meant "out
of stack space".

A more careful reading of the KB article you referenced shows there is
indeed such a term as "stack overflow". (Which I've never encountered
before.)

My apologies for the carelessness. Thanks for persevering!
On Wed, 25 Feb 2004 19:40:07 -0500, Mike Storr <st******@sympatico.ca>
wrote:

Your example does exactly as I had mentioned. Runtime Error 28 - Out of
Stack Space, not the same as an Overflow.

[TC]

Jim, I still feel that your interest in stack issues, will not help you
solve your problem. The reason why the Access books do not explain the
stack, is - IMO - that it is something which you seldom, if ever, need to
know anything about, when writing Access VBA.

Your problem sounds much more like a db corruption problem, or a software
install problem, to me. The KB article was interesting, but I predict that
nothing in there, will solve your problem - unless you have an unbounded
recursion (which I suggested before).

Let us know if/when/how you eventually solve it :-)

Cheers,
TC
"Jim" <ji**********@nospam.virgin.net> wrote in message
news:78a%b.20712$ft.11012@newsfe1-win...

Thanks to all who have answered my questions. Your answers have been
extremely useful and I've learnt things that I doubt I'd ever find in books (and I've tried pretty hard...)

I'll try out some of the suggestions tomorrow and will reply with my hotmail login (can't use NNTP through the firewall at work for my ISP).

Cheers
Jim

[Mike Storr]

He may very well have been mixing them up, but when you're diagnosing
things, the terminology becomes important. Maybe I'm just being to literal?
Wash your hair before going outside.
"Matthew Sullivan" <Ma**@NoSpam.com> wrote in message
news:nr********************************@4ax.com...

OK, I've got my head out of my *ss now....

When the original poster said "stack overflow" I assumed (apparently
incorrectly) that he was mixing up his terms and actually meant "out
of stack space".

A more careful reading of the KB article you referenced shows there is
indeed such a term as "stack overflow". (Which I've never encountered
before.)

My apologies for the carelessness. Thanks for persevering!
On Wed, 25 Feb 2004 19:40:07 -0500, Mike Storr <st******@sympatico.ca>
wrote:

Your example does exactly as I had mentioned. Runtime Error 28 - Out of
Stack Space, not the same as an Overflow.