Link to home
Start Free TrialLog in
Avatar of Mitch Schwartz
Mitch Schwartz

asked on

ACcess 2003 Corrupted data (nothing helps)

My Access db has legacy tables from my client, but one of them has corrupted data. I've tried everything I can think of: (1) Exported into a clean db, (2) Used query to make a  table from the original one. Nada.

I have one combo box filtered by the value in another. But the filtered one does not recognize the values in the 1st box. Instead of using the Forms![frm]![object] to refer to the first box , I even put a number in the filter expression of the 2nd box. Still doesn't recognize the value.

I'm embarrassed to admit how many hours went down the drain before I realized it was the data.
Avatar of mbizup
mbizup
Flag of Kazakhstan image

Do the values in the 'corrupted' table look like normal alphanumeric values or do they look odd, like hieroglyphics (indicating corruption)?


If the values look normal, it could be that the data contains leading/trailing spaces or invisible control characters such as line feeds, etc that are preventing your criteria/comparisons from matching up where you would expect.  If this is the case, you can run an update query to clean up the data once you identify what characters need to be removed.

Can you post a sample database containing just the relevant tables wirh some of this data and the form/combo boxes you are working with?  Mask or remove any sensitive data before uploading the sample.
1. Make a copy of the DB.

2. On the copy, remove all indexes on the problem table.  Also remove all relationships.

3. Create a fresh DB.

4. Import the tables, with structure and data, expect for the table in question.

5. Import the problem table, but with *structure only*

6. Link to the problem table in the new DB to the old corrupted DB.

7. Create an append query to move the records in chunks.

  You may have to repeat this several times to narrow things down to the record(s) that are causing problems.

With all that said, on this:

<< I even put a number in the filter expression of the 2nd box. Still doesn't recognize the value.>>

 Does the rowsource the combo use display data correctly on it's own? Is it set to the table directly or does it use a query?

Jim.
Avatar of Mitch Schwartz
Mitch Schwartz

ASKER

Just an update on your comments:

1. The data looks normal. No gibberish.
2. The rowsource uses a SQL statement within the control (no separate query)
3. If there are bad characters in the data, it's tough to identify them

I am am now trying the procedure suggested by MDettman.

I have also attached a file. When you open the form, and select an office, the "Agents" box populates correctly. When you do it a second time, the data does not change. Strange, huh?
MS3930-UploadFile.zip
It might be that the form is corrupted, not the data.  Try making a brand-new form and see if the combo box works correctly.
Not the form. Created several.
Your attached file link in the above doesn't work for some reason.  Please upload it again.

Thanks,
Jim.
Here's the file.
MS3930-UploadFile.zip
Your data looks fine.

You just need to requery your Agent combo box to refresh the list after selecting an office:

Private Sub cboOffice_AfterUpdate()
cboAgent.Requery
End Sub

Open in new window

ASKER CERTIFIED SOLUTION
Avatar of mbizup
mbizup
Flag of Kazakhstan image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I thought I had put it in the Afterupdate event of he office box. Anyway, when you all made that change, did it work correctly? Remember, it works when you make the first selection, but not after that.
Did you try making that change yourself?  Note that you cant simply change the name of the sub in the code - it won't automatically connect to the right event procedure.  You need to make sure the words "Event Procedure" are showing in the box next to After Update in the property sheet.  Clicking the "..." and choosing Code Builder automatically makes that connection for you; editing an existing event procedure does not.

< Anyway, when you all made that change, did it work correctly?>
Anyhow it does appear to be working correctly.  Here's the sample with that change in it:
MS3930-UploadFile.mdb
The solution was actually in two steps:

1. The requery was in the wrong spot (an amateurish error)

2. The data was tainted. So I migrated it into clean tables, which I recreated manually, and then used DAO & recordsets to save it in the new ones.

Thank you for your timely help.