Data not seen

[Monty51]

Up front, thanks for any help or advice I'll receive on this issue. You folks sometimes (ok, often) talk over my head, but I can usually garner some guidance out of discussion here.



I'm responsible for an Access application used to track aircraft usage at a flying club here in the plains states. I recently took over administration of this program for several reasons not so important to my problem, but as a background:

1) The program was developed by a person who has long-since deceased and didn't leave documentation, and
2) I'm the only one that knows enough Access to get in and recover passwords for the program.

The program is mounted on one, central computer, and that directory is shared out to two more computers (Windows XP, by the way). I presume the reason it's like that is so anyone could log in at any of the three computers, access and edit the data (as allowed) and the data is located in one, tidy place.

Until recently it's been working flawlessly. However, as part of the tracking program, this application records discrepancies reported by pilots, and anyone is able to view them (as it should be) until recently. It turns out that we can't see discrepancies for one airplane in particular. And only the one airplane.

Discrepancies are recorded in a table of their own, indexed (more correctly - sorted) by the aircraft's tail number. For some reason, discrepancies attributed to one particular tail number aren't shown when requested. They normally get displayed as part of a subform in a tab on a full screen form. This is the way it's been working forever - until about a week ago.

I've looked at the underlying table and all the information is there, it's just not displayed for that one tail number. No editing has been done to the underlying forms/queries/tables, etc., because no one but I have the passwords to get into the design functions of the database. I've cross-checked the on-line software with the installation software and all the appropriate form/query/table configurations are identical.

I'm at a loss on where to look next on this problem. I'm hoping someone out there will have come across something similar and has some insight into this situation.

By the way, it's an Access 97 database. It was bundled as a minimal installation, without the ability to run the full Access on its own: I have to open the database in Access 2003 to look at things. I don't know if that's an issue, but it's never been one before.

Regardless, does anyone have any thoughts on where to proceed with T/S'ing?

Thanks again.

[CJ_London]

sounds like the issue is with the data - check to see if the tail number has a space at either end or illegal characters

[Monty51]

"Sounds like the issue is with the data - check to see if the tail number has a space at either end or illegal characters"

Since the tail number is a text field (contains a string like 'N1234T') and the value is selected from a drop down list, I wouldn't think that's an issue, but I suppose it's worth a look. I'll see if the values in the drop down list got corrupted. That would make the query fail. The discrepancies selected for viewing come from a query like 'WHERE TAIL_NUMBER = N1234T', and the results populate the subform. The drop down list is also used to add a new discrepancy for that tail number. I'll look and see if something went wrong in that routine.

Thanks!

[CJ_London]

not sure if you didn't bother in your post but N1234T needs to be surrounded with quotes

[Monty51]

not sure if you didn't bother in your post but N1234T needs to be surrounded with quotes

I just didn't bother to be technically correct.

[NTC]

Without wanting to sound snide - there is a point where excessive frugality becomes expensive - and yours is truly a case in point....upgrade to the current version of Office and a current operating system...it may not solve your problem but do it anyway......

[Monty51]

Without wanting to sound snide - there is a point where excessive frugality becomes expensive - and yours is truly a case in point....upgrade to the current version of Office and a current operating system...it may not solve your problem but do it anyway......

I would love to do that, but since there's not documentation and we're not sure what kind of changes would occur with importing the DB to a later version of Access, management's a little (a lot) hesitant to do that, and they hold all the cards. As for myself, I can see their point. As the DB admin, without documentation I'd be afraid to open that can of worms. However, a plan is in the works to write another one in a later version of Access, with some appropriate changes.

On a lighter note, the problem has been solved. It seems there was a policy change that didn't filter down all the way to a particular user and that user archived all the records in question...which means for this app the records weren't visible. Having cleared that up, we un-archived a year's worth of records and they're visible, much to everyone's delight.

Thanks for all the input folks. I do appreciate it.

[orange]

Monty51,

So now that the heat is off, you could do some documentation to be prepared for next time.
Good luck.

[Monty51]

Monty51,

So now that the heat is off, you could do some documentation to be prepared for next time.
Good luck.

Got that right.