none
MS Access 2007 - Problem (crashes) using memo fields in forms

    Question

  • I have MS-Access as a frontend to an sql-server database. i have a table including one ntext field (which is linked as a memo field to my frontend). The application is running under Terminal-Server (Multiuser). Dynamically, when entering bigger text into the memo-field, Access is crashing. In any error-situation the user is only typing in text - suddenly crash. User calls me - we try together again,  after starting the program anew - no problem in entering the complete text. The problem is not directly reproducable.  About three month ago i read about an expirience by a programmer in the web: when deactivating the statusline in the access-options this problem is solved. I tried this and it worked well till now (one week ago). I don't know what impact the statusline should have to the memo-field, but it worked well till now. Since about one week the problem arises again. Dynamically crashes when entering big text. There was one change till the successful period (over 2month). Change from SQL-Server 2005 to SQL-Server 2008. Could this be the reason? Is there generally a bug in the enter routine of the memo fields. Has it a problem only with terminalserver?

    ps: i have tried the memofield with direct binding to the record and also with filling and reading an unbound field - same result!

    hoping to get some ideas - thanks

    Werner

    Friday, August 20, 2010 12:43 PM

All replies

  • Hello Werner,

    Thanks for posting. This is a forum for programmers. Your question is more an end-user level question, not a developer (programming) question. You're more likely to find people knowledgeable in this area on the Answers sites:

    Microsoft Office for Business Users: Visio, Project, InfoPath, and Access:
    http://social.answers.microsoft.com/Forums/en-IN/addbuz/threads.

    If you have any concern for this post, or I have mistaken this scenario, just feel free to follow up. Have a nice day.

    Best regards,
    Bessie Zhao - MSFT
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Monday, August 23, 2010 6:37 AM
  • Hello Bessie.

    Thanks for your reply. I am a programmer and have this problem in my application for one of my clients. It's a good idea to post my question also in your mentioned forum. I think the problem is relevant for both (programmer and endusers). I am not sure, but my feeling is, that possibly there is an instability in the internal handling in the enter-routine of the memofield (maybe there is a connection in using terminalserver). There is no specific handling set by myself (no triggers) in this form and i have this crashing very dynamically (not directly reproducable). But erverytime the error arises the user has typed some text - suddenly crash - so he stays in the enter-routine of the memofield - no possibility for me to interact by the program in this situation!). I think the problem is interesting for programmers and endusers, because if there is really a problem in the internal handling of the memofield (whatever the reason maybe), programmers should take care in using this object.

     

    Thanks

    Werner

    Monday, August 23, 2010 7:32 AM
  • Werner,

    Is it possible that as they are entering data they are entering (either on purpose or by accident) any extended/international language characters?  I had an issue recently which turned out that when entering a double-quote character, the system "held" the keystroke waiting for the next character, and when it got it, it would either print both characters together or show a forign-language accented character (somehow my keyboard was set of English-International rathern than for US English).

    Perhaps you could build a keystroke logger to help debug this sort of crash.

    if you grab the keystrokes in the _change event of the textbox/richtext control (whatever you are using), you can grab the keystroke and dump it directly into an output file on disk - overwrite the file on each record or something - unless/until there is a crash which should be detectable with a file rename trick on a normal exit -vs- a crash.

    This way you could get some sort of useful debugging data for a postmortem analysis.

    These sorts of hard-to reproduce errors can be the worst sort of PITA to track down...  :-(

    Monday, August 23, 2010 2:58 PM
  • Hello MarkB_08109

    Thanks for your reply. I m sitting in Austria, so we use the german keyboard (european extended set with Umlaute ÄÖÜäöüß). Sometimes i was in the same direction as you. My idea was, that it could be some unvisible Controlcodes (or a combination of characters which are bad for the input-driver) the users are entering which produce the crash. So i will pick up your idea of fetching the input character by character into a logfile. Pretty idea - thank you!

     

    Monday, August 23, 2010 3:35 PM
  • lingi,

    thinking about it a bit more, _keydown might be the better place to grab the keystrokes (before the control tries to process them?)

     

    Monday, August 23, 2010 3:49 PM
  • Hello MarkB_08109

    ... will try this in the evening and test how it influences performance. The problem is that this application is running in a terminalserver-farm, so i have to look at the performance influences (14 virtual servers with about 300 clients). I will give only one user this testapplication (maybe the one who had the biggest problems with it - so the chance is high to get the error-situation). So we let him work some days this way and look what happens ... Will give you a report when i have some new information.

    Till then - thank you for yor help (any additional ideas are welcome!)

    Werner

    Monday, August 23, 2010 4:09 PM
  • Hello MarkB_08109

    I have tried to implement the _keydown trigger (write down a flat file with th keys entered. Looks good. Have spoken with my users, soon they will test it for some days.

    The _keydown-trigger is good for it, but there are some keys which are not fetched (instead there is done some action). At this moment i have no overview which key-combinations are not fetched. I tried it with Ctrl 'A' (Ctrl + letter A), Ctrl 'B', etc. or the function-keys F1 to F12.

    I will continue to analyze the input behaviour of the user.

    Will respond as soon as i have new results ....

    Thanks

     

    Tuesday, August 24, 2010 8:36 AM
  • This problem is nothing to do with the use of SQL as I get it from time to time using an Access 2007 database containing tables and forms. It happens about once a month or so and losses all of the data being entered and some previous records. This problem has always existed on Access 2007.  Deactivating the status line only makes it less likely to occur and is not a fix. I would appreciate info about a fix if you find one.
    Tuesday, March 22, 2011 10:32 AM
  • I have a completely english system and still get the problem I don't use strange characters only simple ASCII text in the memos.
    Tuesday, March 22, 2011 10:35 AM
  • I have had similar problems.  Textboxes in Access 2007 will crash unpredictably when editing text of 5000 characters or so (as tested under Windows XP SP2).  This happens even if the textbox is UNBOUND.

     

    It's a bug in the textbox widget itself.  My questions is how can I work around it?  My users are having serious problems with this (and, thus, I am too).

     

    If anyone knows of a work-around or has a suggestion, I would be very grateful.

     

    Eric

     

     

     

    Saturday, June 25, 2011 12:10 PM