Access crashes

[MarionD]

Hi Folks,

I have a problem that I need to solve drastically, I really hope someone can help me:

Problem: Access crashes during data input in a certain form. – Not always on the same field, and not always on the first record. Sometimes I can input 2 or 3 records and it crashes on the 4th. The "modul" that the crash shows is always the msjtes40.dll

Action taken so far:
1. Checked the version of the msjtes40.dll – it’s the latest
2. reregistered the msjtes40.dll
3. Created a new DB imported everything
4. Repaired the Db
5. decompiled and compiled all the code (which I have been through with a fine comb - there is no complidated VBA on the form at all.)
6. recreated the form entirely
7. Checked the Source of the form for any funny records
8. reinstalled the entire Office XP Professional

I really don’t know what else I can do!
If anyone has had this Problem before… please docmd.HELPME

Marion

 

[Ron_dK]

Maybe there is something wring with the msjtes40.dll registration.

You might try the following :

Click Start, and then click Run.
Type the following command line in the Open box, and then click OK.

regsvr32.exe C:\WINDOWS\system32\msjtes40.dll ( XP)
or
regsvr32.exe C:\WINNT\system32\msjtes40.dll (Win NT or 2000)

Hope that helps.

Viel Glueck.

 

[MarionD]

Hi Rak, Thanks - have done that along with the others that the Knowledge Base recommends msjter40.dll, msjet40.dll.... it still crashes

 

[Ron_dK]

Marion,

Maybe it's a server problem ?

http://www.kbalertz.com/kb_838306.aspx

 

[MarionD]

hi there,
Am testing on my own machine at home - no server involved. Both Back-end and front end on local D:\ drive.

ich bin echt verzweifelt!

 

[Ron_dK]

Leider kann ich Ihnen nicht irgendwie weiter helfen,
guess you will have to wait for the real experts to log in.

Cheers, Ron

 

[MarionD]

Thanks anywy Ron.
Have a good day!

 

[KenHigg]

- Try it with no data in any table
- Try it with just the suspect form in the .mdb
- Try it on another computer

Hum, That's about all I can think of at the moment...

 

[The_Doc_Man]

Access crashes during data input in a certain form. – Not always on the same field, and not always on the first record.

Computers are deterministic, and Access is way too stupid to behave in a non-deterministic manner for something so simple as data input.

"Not always on the same field, and not always the first record" - implies that the problem isn't where you think it is. I would first check to see if you have any other references that are improperly defined.

Am testing on my own machine at home - no server involved. Both Back-end and front end on local D:\ drive.

This is a good thing to know - it eliminates lots of networking possibilities - though not all of them. Is there a chance that something "behind the form" is trying to do anything online, like some complicate lookup from a cooperative web site?

Issues that come to mind involve things you can run overnight if you have them. Do you have a disk surface diagnostic? Do you have a memory diagnostic? The symptoms you describe CAN be caused by accidentally running into a bad memory spot or bad disk spot that is right near where you working. Can you compact the drive (NOT necessarily the database, though that action doesn't hurt either...)?

Another possible cause is related to the machine settings for virtual memory. If you run out of VM, you die when Access tries to expand. There is a little-known requirement that you must have swap space available to hold your expanded program. Too small a swap space will eat your socks every time. I think it is because Windows wants to allocate the swap space, outswap you, and then inswap you larger. Or something similar to that. If you reach a size limit and cannot grow larger, ... BANG ZOOM.

A possible problem is swap space fragmentation, which isn't SUPPOSED to cause trouble... but we ARE talking about a Microsoft product, after all. Look for a difference in the number of records you can add when you have recent and not-so-recent reboots. The more you run, the worse memory gets. It could also be a memory fragmentation issue, though again that isn't supposed to happen.

"crashes on a certain form" - is this the only form you run? Does it involve opening and closing files "behind the scenes" ? There is an old rule about "close what you open" that always bites you on the butt with Access. File handles tend to be a limited resource.

Depending on your version of Windows, the Accessories >> System Tools might lead you to a performance monitor that would let you watch system resources. If you can open that in one window and Access in another, you can see if any resource goes to "0 available."

Here is one that you might not have tried yet. On your home machine, you should be able to do this. Run your form, enter your data, let Access crash. Now immediately note the time on your system. Get into Accessories >> System Tools (usually there unless it is under administrative tools) >> Event Viewer. Look for the APPLICATIONS event where Access crashed at that time and expand the error message to see what it tells you. Report back to us. Also, that error might be something you can search in the MS Knowledge Base to see if someone else has run across the same problem.

That ought to give you a few things to look at.

 

[MarionD]

Thanks for both the replies!

This I must admit is the strangest thing I've had in 15 years of programming!

This problem was reported by one of my customers, and my first thought was of course "funny data" - since then more and more customers reported the error. I immediately asked to have the data sent to me as it was not happening on my machine. As soon as I loaded the data, it happened and then on my data, as well. Since then on any data I load.
I have run all anti virus anti worn anti everything I have - all clean. It cannot be that anyway, as different customers have the problem. I can open and input data directly in the table. I cannot find anything quirky with the data.
My machine is a new machine, with plenty of ram etc...

There is nothing complicated behind the form, it is the simplest input into 1 table. Only things like names, dates, address etc.

I will go through your suggestions 1 by one Doc, and report back if I achieve anything.

Thank you so much for your advice and time!
Marion

 

[MarionD]

Hi Doc,

I found and looked at the event viewer as you suggested, but it gives basically the same info that it gives at crash time namely.

Faulting application msaccess.exe, version 10.0.4302.0, faulting module msjtes40.dll, version 4.0.8618.0, fault address 0x00008b6a.

After reinstalling Access, I would have thought that any corrupted .dll would have been replaced/repaired.

What I have noticed is that after leaving each field in the form, the cursor changes to hourglass for a split second, although there is NO code behind the Field or on the on current of the form. It seems to be doing something... but what? When it crashes the "split second" takes longer and then with the hourglass still showing... crash!

Thanks again for your trouble and interest.

 

[The_Doc_Man]

This is good in one sense - at least you know that at the Windows level, the error report corresponds to other issues you are seeing. If the Event entry and the screen report had been different, the Event entry would have been the right message.

I have to admit I've not seen one do that before when there is no VBA behind the screen.

Failing on multiple machines tends to rule out the "bad spot" theory. I can believe a bad spot on a machine but not the same spot on two machines. So it is the DB itself.

"On any data I load" - tends to eliminate data as the problem. It is a bug in one of your modules. The GOOD news is that you can reproduce the problem. Is it small enough that you could ship it to Microsoft and ask them if they have any clues? Since customers are involved, it might be worth your while to pay for the consultation.

 

[MarionD]

Hi there,

I'm still wrestling with this problem!

I have one very strange occuence that I think may be responsible for the crash.

On the main form, I have several sub forms. When I open the main form, even before the "on open" event of the form is started, the "on enter" event of one of the fields on a sub form runs. the code here just sets the row source for the combobox. The sub form is on the 3rd Page of a tab form. The tabstop of the sub form is "no". I cannot explain why this code runs at all, before I enter the field on the subform.
If anyone has any advice I would be very happy!

 

[Ron_dK]

Maybe it's something of the relationship of the main to subform(s).
I would suggest the remove the subform from the main form , start up and enter data in the main and subform seperately.
Try changing the child/master fields or temporarely delink any relation.

Hope this helps.

 

[The_Doc_Man]

Rak makes a good suggestion. You can "enter" data in certain cases on linked forms where the field names match textbox names. If the textbox is also linked to something else in some complex way, you have an "automatic" data entry where you didn't expect one.

 

[MarionD]

Hi again anf thanks for all thhe replies and suggestions!
soo..........

this is what happens.. I assumed that when a main form with different subforms is opened, the on open of the main form is executed before any sub form routines. This is incorrect. I stripped the form piece by piece until I was left with only 4 unbound combo boxes on the main form and one subform. I checked that the tabstop position of the combo boxes were before the sub form. Then I put only message boxes on the got focus and on enter of the first field in the sub form, and on the on open of the main form.
When the form is opened, the on enter, then the got focus of the field in the sub form, then the on open of the main form are executed.
I added another sub form, and put the same msgboxes on the 2nd sub form. Also these were executed before the on open of the main form.
Thinking, maybe the form was corrupted, i created a new db, a new form and new sub forms and the same happens. So I assume this is access is how access does it.
Even worse, this same procedure is followed after each update of any field in the main form!

My problem was caused because I had on the on exit event of the first field a procedure that was to be carried out, if there was no value in the field. The on exit event was also triggered, and there was no value in the field. This sent access on a wild goose chase, until it eventually gave up the ghost!

I hope I've explained properly... and the moral of the story is... don't use the onenter, gotfocus, lostfocus and exit events of the first field in any sub form!!

Marion
Knittlingen Germany

 

[Ron_dK]

It's good to see that you sorted this one out Marion.

Viel spass,

Ron