OMG - This is crazy - Anyone seen this before?

Maxis37

Registered User.
Local time
Today, 06:52
Joined
Jul 10, 2013
Messages
20
We have a record called a CCR with only five fields in it. You can have many CCR's to one parent. One of the fields in the CCR record is a MEMO field called TOPIC. The user can hit Shift-F2 and the ZOOM Dialog Box comes up and they enter text. Everything's great so far. But every so often a CCR is created that kicks the user completely out of the database. No messages, directly from the ZOOM Dialog Box to completely out of the database. And it does NOT save that record when it occurs.

Here's the specific example where we can duplicate the error: The record has 279 characters in it and ends with the word "access"; if the user puts a period at the end of that sentence and hit's the OK in the ZOOM Dialog Box, it kicks you out of the database. Any single character, a period, an "x", any character in the 280th position you get kicked out and it doesn't save the record.

Now if you put 2 characters; two periods, two "xx", another complete sentence everything is fine and the ZOOM Dialog Box closes and the record is updated. But if you back space to the 279th character, and put in that single 280th character, you're kicked out of the database. You can put more character or take away characters, but if the TOPIC field for that particular CCR ends at 280 characters you get kicked out.

I've tried compact and repair on the database (it's a split database), I've tried to stop the code in an EVENT but it never seems to go BACK to an event, it just kicks you out of the databases from the OK button on the Zoom Dialog Box. I've checked for special characters as well and there are none.

We're running Windows 7 / Office 2010 on our laptops, but both the Front-end and Back-end of the database are ACCESS 2003.

Has anyone seen something like this before? Any hints on a google search I might do, or a Microsoft link would greatly be appreciated.

Shawn...
 
Try importing everything into a new database.
 
Just did it - created new database, imported all objects. Same results! :(
 
Additional Information after creating new database and doing import. ANOTHER CLUE to the Mystery! If I simply hit the "end" key in the TOPIC field which puts the cursor on the last character of the string (in other words, we do NOT use the ZOOM Dialog BOX - Shift F2), it accepts the 280th character and saves the record. It ONLY kicks us out when we use the ZOOM Dialog Box, put in the 280th character, and then hit OK.

Is there an EVENT for the ZOOM Dialog box I could put a BREAK in? It appears the ZOOM Dialog Box is having the issue. Does that additional clue help anyone?
 
You could emasculate the db to the point that just the error-generating element remains and post that skeleton here for general merriment and abuse :D Then someone with A2003 could try it, because perhaps it is the 2003/2010 combo that is the culprit?
 
What happen if you look at the Table and check if there is not corruption in the contents of one of the Memo fields.

Simon
 
OK SpikePL - ANOTHER CLUE! You may be on to something here.

I moved the Front-end and Back-end to a REMOTE PC that still has XP and OFFICE 2003 installed. I wish I could post the database, but it's not allowed where I work.

GUESS WHAT! NO ERROR! So what does that mean? Why does Win7/Office 2010 running ACCESS 2003 database fail in the ZOOM Dialog Box? Am I missing a REFERENCE in my compile library for the Win7/Access 2010 version?

Visual Basic For Applications
MS Access 14.0 Object Library
OLE Automation
MS DAO 3.6 Object Library
MS Visual Basic for Application Extension 5.3
MS ActiveX Data Objects 2.5 Library
MS Word 14.0 Object Library
SEP Date/Time controls
MS Excel 14.0 Object Library
MS Outlook 14.0 Object Library
MS Scripting Runtime

Any other hints to try? Your suggestion help provide another piece to the puzzle.
 
Another thought - are you using rich text format? 2003 uses the rtf coding, whereas 2010 uses html coding - not sure how it copes with the mixed environment but it might be producing a conflict.

try updating a copy of your backend to 2010 and see if you still get the error
 
Okay - yet another CLUE! I can NOT update the back-end to Access 2010 at this time; the back-end has to remain Access 2003 because of interface/compatibility issues to other databases it interacts with. HOWEVER, I did update the front-end to Access 2010 with new Access 2010 references on the compile.

SAME FAILURE with a Front-end Access 2010 and a Back-end Access 2003. So far, the only NON-FAILURE is Front-end AND Back-end Access 2003 running in XP test we did above for SpikePL.

The field is define in the PROPERTY on the sub-form as Text Format = PLAIN TEXT. It is NOT set to RICH TEXT.
 
I've done several compact and repairs thinking initially that the record was corrupt. But you can update the record and put more than the 280 characters and it saves it just fine. You can put less than the 279 characters and it saves it just fine. It's just one it ends with a character in the 280th position that it kicks you out of the database. I also did a new database and imported all the old tables, forms, etc. Still had the error after that in a new database.
 
I would sugget that you create (not copy!) a new table similar in structure to the one that currently holds the memos. Temporarily link your form to that table plug in some dummy data and see if the error persists.

Do two: one in the updated front end and then one in the backend
 
Okay - i created a front-end and back-end in Access 2010 format. Same failure. Now I'm going to try copying the table per SpikePL's suggestion.
 
I can NOT update the back-end to Access 2010 at this time
I appreciate that, but if you create a copy and link your 2010 fe to the copy to see if you still get error, it will tell you something
 
Okay.... created copy of the table, deleted original table, renamed copy of table, refreshed link of new table, and still get FAILURE in both the versions. Version 1 FE 2003 BE 2003 on Windows 7 / OFFICE 2010 platform. Version 2 FE 2010 BE 2010 on Windows 7 / 2010 platform.

:( I'm very sad... I thought were were narrowing in on the mystery wagon! :)
 
A clue I forgot to you mention. I just happened to have this record that we can DUPLICATE the issue with over and over. But in the real world, it's not always the 280th character. There might be 3000 characters in one record TOPIC field and it fails on the last character, or 50 characters in one record TOPIC field and it fails on the last character.

This example is the first time we've been able to duplicate. All the others just kick you out of the database when you hit OK on the ZOOM Dialog Box. :(
 
Surely you did not COPY that table?
 

Users who are viewing this thread

Back
Top Bottom