Weird version dependency problems

[prn]

Hi folks,

I've come across a couple of the oddest behaviors that I have ever seen and wondered if anyone else has had anything similar, and if so, whether you have any suggestions for me. I warn and apologize to any brave souls that the following description will be long -- it has to be -- but if you feel brave enough to read it, I will thank you.

Both of the phenomena seem to involve version dependencies. I had been using XP with Office 2003 and have recently upgraded to Win7, still with Access2003 for development. The access application in question has multiple users with different combinations of OS and Office versions. (And, frankly, is really pushing the limits for what an Access application should be expected to do.)

One of my main clients recently got a new computer with Win7. Last week she called and asked about why one field on a particular form (actually a continuous sub-form, which will be interesting later) was not showing. Naturally, it was fine for me, so I trotted on over to see what was going on. My first thought, of course, was that for some reason, the text color was the same as the background color in that text box, so my first test was going to be to select the text and see if that made a difference. To my surprise, as soon as I clicked in the text box, without actually selecting the text, the data became visible (black on light blue as it ought to be). I clicked in some of the other instances of the same field and they became visible too. After doing this to several, I scrolled back up and found that the text in the first couple had disappeared again.

I have tested this with several other users and found that 3 of the 4 with Win7 and Access 2007 show the same weird behavior, but 1 of those 4 gets normal behavior where all of the instances of that field are visible all the time as they should be. Everyone else I have checked, with XP/Access2003, XP/Access2007 and Win7/Access2003 are normal.

I have varied the fonts, font color, background color, screen resolution and "Custom text size (DPI)" (from the Win7 "Personalize" settings) with no differences. Somehow the one user for whom it works must have some different setting, but I have no idea what it could be. Does anyone here have any suggestions?

The other strange thing, which also happens only with the Win7/Access2007 combination also seems to occur only on a single (different) form in a single combobox where the combobox is populated in the usual way. The row source is a table (Delivery_Mode) with a key field and a text field. The control source is a field (CTM_Delivery_Mode) in the table that is the data source for the form and is intended to hold the id to the row source. When my user attempts to populate that field by picking an item in the combobox, she gets the dreaded error message "The Microsoft Access database engine cannot find a record in the table 'Delivery_Mode' with key matching field(s) 'CTM_Delivery_Mode'."

Again, this error occurs only in this one combobox (of all the different comboboxes populated this way) and only on the Win7/Access2007 combination. Other OS/Access version combinations all seem to act normally. Again, I have tested against XP/Access2003, XP/Access2007 and Win7/Access2003 from different workstations. The data for all of them resides in tables linked from SQL Server, not on the individuals' workstations, so I know that the data is not the problem. The configurations tested were using the same build of the Access application. I even relinked the relevant tables just to make sure, but if the links had been bad, I would not have expected to see the relevant data in the first place.

I would be grateful, even thrilled, for any suggestions.

Thanks,
Paul

[topher23]

For the first issue, I'd check Access's option settings on the PC where the combination is working properly against the settings on one where it's not working properly to see if there are any differences. One checkbox can sometimes make all the difference.

That's all I've got. My company is still testing Office 2007 and Win 7 for compatability with our other business software, so I've yet to encounter any of these issues. Fingers crossed that I'll see very few of them!

[ChipR]

I haven't run into a combo box problem like that, but you could unbind the combo box and copy the value to a hidden bound textbox after update, after checking for .listindex >= 0.

[prn]

tpoher23: Thanks. I will check those settings. I guess I was lax there. Frankly, I would be very surprised if any of those people had done anything with their option settings, but you're right. And I will check those.

I'm not at all surprised that you have not run into these problems. Each of them is happening to me only in a single field in a single form in an application with approximately 200 forms. (This application has grown way out of the realm of reasonableness.) I'm certainly at least the fifth developer to have worked on this app, so there are way too many different styles of doing almost anything incorporated in it.

ChipR: I did put in a visible textbox bound to the same key field just so I could confirm that CTM_Delivery_Mode was what I expected it to be. And it was. I'd really rather not introduce the extra complexity of an additional AfterUpdate event handler if I don't absolutely have to, but it may be worth trying just to see what happens.

Thanks for the suggestions. I'll let you know if they help.
Paul

[ADezii]

I had a similar problem back in April of 2006, and unfortunately never resolved it. You can take a look if you like, maybe something will pop out at you:
http://bytes.com/topic/access/answer...-sub-form-data

[prn]

ADezii: That's really wild. Your problem was almost the opposite of mine, with your text disappearing rather than mine being initially invisible and then appearing, but it's just similar enough (underlying data actually present; subform; only one field; the change in visibility occurring as the fields are entered; front-end/back-end architecture; etc.) that one has to think they are related in some way.

The fact that yours occurred using Access2003 whereas mine seems to be occurring only with the Access2007/Win7 combination is a real confounding factor. Tentatively, I think I have to revise my overall hypothesis of this being primarily a version problem to thinking that it may reflect a very obscure longer-standing Access bug that is manifesting itself in my case only in this configuration. However, I'm not sure that I can see any immediate help from that change. :/

Thanks,
Paul

[NeoPa]

I don't have any of these problems myself, but I've always found Allen Browne's Database & Training to be a good resource for known Access bugs and features (Scroll down to Flaws in Access section). May be worth checking out.

[prn]

Hi NeoPa,

That's true. Allen Browne's site is a great reference (probably the best single reference site I have found). Unfortunately, I haven't found anything that appears relevant to these particular problems. It's always worth taking another look there. In fact, I just did and noticed a relatively recent topic that looks promising wrt a different issue, so it's good that I looked again anyway.

Thanks,
Paul

[NeoPa]

Well Paul, you know it's always much harder to help you experts. The questions are usually a lot clearer and properly explained, but you only ever ask difficult questions because you already know all the basic stuff :D

[prn]

Hi NeoPa,

I'm certainly more than capable of asking dumb questions, sometimes even very clearly. :-/

(But a pointer to Allen Browne's site is hardly ever a bad idea.)

Thanks,
Paul