We have an Access 2000 app running over a network with a Windows 2000 server. On two workstations, a combo box that is looking up a specific field in a specific table does not work when you type the data and press ENTER. It shows the data if you pull down the list and you can point at the data you want and click on it and it finds the record correctly. When you type in the data (which IS in the table) the program will tell you it is not an item in the list. This same combo box works correctly in all respects on all the other workstations. I have tried updating the workstations with a new copy of the mde file. I have uninstalled the Access runtime and reinstalled it. Has anyone run into this problem?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Intermittent combo box functionality 1
- Thread starter diamondsc
- Start date
-
1
- #2
My guess is that the data doesn't exactly match what you're typing. It could be that it contains a non-displayable character, for instance, or leading spaces.
Try typing a space in the text part, and see if it autocompletes with the desired entry. If so, the entry has a leading space.
Otherwise, write some VBA code to do a DLookup() for this value and put it in a variable. Then use code to translate it into ASCII character numbers:
strValue = DLookup(...)
For i = 1 To Len(strValue)
Debug.Print Asc(Mid(strValue, i, 1))
End If
In the list of numbers, anything less than 32 or greater than 127 is a non-displayable character, and you can't type it. You probably need to "clean" this data in the Row Source table.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
Try typing a space in the text part, and see if it autocompletes with the desired entry. If so, the entry has a leading space.
Otherwise, write some VBA code to do a DLookup() for this value and put it in a variable. Then use code to translate it into ASCII character numbers:
strValue = DLookup(...)
For i = 1 To Len(strValue)
Debug.Print Asc(Mid(strValue, i, 1))
End If
In the list of numbers, anything less than 32 or greater than 127 is a non-displayable character, and you can't type it. You probably need to "clean" this data in the Row Source table.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
- Thread starter
- #3
Actually, the data being typed does match the data in the table. The data is numeric ranging from 1000 up to around 4400 and increasing daily. As you type in a digit, normally the first number with that beginning digit will appear in the combo box. This does not happen no matter what digit is entered. And, as I said, it is only happening on two workstations out of ten. I tried uninstalling the app and the access runtime and reinstalling it but that didn't help. This only happens on combo boxes that are accessing this one field. All the other combo boxes throughout the app work correctly. Also, this app has been running since the first of the year and this problem has just occurred. There have been no changes to the workstations that I am aware of.
I overlooked that this is only happening on certain workstations. Very odd!
I thought it might be that those workstations are using a different version of the ComboBox control. But no, that would affect all the combo boxes in the application.
Do the workstations have individual copies of a front end database, or is everybody launching it directly off the network?
Since it seems to be specific to a particular field, the back end might be involved. Is the data in Access, SQL Server, Oracle? Is everybody using the same back end?
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
I thought it might be that those workstations are using a different version of the ComboBox control. But no, that would affect all the combo boxes in the application.
Do the workstations have individual copies of a front end database, or is everybody launching it directly off the network?
Since it seems to be specific to a particular field, the back end might be involved. Is the data in Access, SQL Server, Oracle? Is everybody using the same back end?
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
- Thread starter
- #5
The front end is distributed to each local workstation. I tried copying a "working" front end app to those machines with no change.
The back end is Access 2000 and is running on a central server, which is Windows 2003 Server. Everyone is sharing the back end.
You can pull down the list in the combo box, see the data, and click on the desired row with the mouse and it finds the correct record. It just will not let you type the data into the combo box to find it.
The back end is Access 2000 and is running on a central server, which is Windows 2003 Server. Everyone is sharing the back end.
You can pull down the list in the combo box, see the data, and click on the desired row with the mouse and it finds the correct record. It just will not let you type the data into the combo box to find it.
I think you've eliminated most of the possibilities.
It seems to be something special about this combo box, in the special environment of the two workstations.
Do any properties set this combo box apart from the others? I'm thinking about things like the bound column, or especially event properties such as On KeyPress.
Differences in the workstation environment are obviously part of the problem, but it would be murder trying to identify them all. You might check for patches, service releases, and system packs applied though.
At the risk of disturbing another workstation, you might try reinstalling the runtime on one that's working properly. There are actually 2 runtimes for Access 2000, with and without something or other, so I'm wondering if that's the difference and you're just reinstalling the runtime that causes the failure.
The worst case is that the problem originated when some other product was installed that contained a later version of some component. Later versions are supposed to be plug-compatible, but it doesn't always work out that way. This is what's commonly called "DLL Hell".
BTW, I don't know if you realize it, but Access will automatically substitute a later version of some object libraries if it finds one. For instance, if you install Access 2002 side-by-side with Access 2000, and MSO9.DLL gets lost because you moved it, Access may fix the Reference by using the Microsoft Office 10.0 Object Library (MSO10.DLL?). It's kind of out there as a possible cause, but I thought it was worth mentioning. (Too bad this is a runtime app and you can't view the references.)
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
It seems to be something special about this combo box, in the special environment of the two workstations.
Do any properties set this combo box apart from the others? I'm thinking about things like the bound column, or especially event properties such as On KeyPress.
Differences in the workstation environment are obviously part of the problem, but it would be murder trying to identify them all. You might check for patches, service releases, and system packs applied though.
At the risk of disturbing another workstation, you might try reinstalling the runtime on one that's working properly. There are actually 2 runtimes for Access 2000, with and without something or other, so I'm wondering if that's the difference and you're just reinstalling the runtime that causes the failure.
The worst case is that the problem originated when some other product was installed that contained a later version of some component. Later versions are supposed to be plug-compatible, but it doesn't always work out that way. This is what's commonly called "DLL Hell".
BTW, I don't know if you realize it, but Access will automatically substitute a later version of some object libraries if it finds one. For instance, if you install Access 2002 side-by-side with Access 2000, and MSO9.DLL gets lost because you moved it, Access may fix the Reference by using the Microsoft Office 10.0 Object Library (MSO10.DLL?). It's kind of out there as a possible cause, but I thought it was worth mentioning. (Too bad this is a runtime app and you can't view the references.)
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
- Thread starter
- #7
That sounds like you're on the right track. There are some things I can check. Got another clue. On the same machine, we have just discovered it is not recognizing or implementing the MID function. There is a report that utilizes the MID function. On the report it prints #Name? instead of the data where the MID function is used. Does this narrow it down any more?
YES! Mid() is a VBA function included in the Visual Basic for Applications Library, which is always the first library in the References list of any VBA program. Thus, there should never be any problem finding Mid(), Left(), Len(), or any of the other functions in that library.
When you start getting messages that these functions are not found, it's a symptom that you have a 'broken' Reference object further down the list. Some library later on is marked 'Missing'.
Usually, the symptom occurs when you start up the database, and in the runtime environment it just shuts down. You seem to be having less trouble than that for some reason, but I'm quite confident that this is the problem.
Unfortunately, in a runtime application you have to way to check the References list. (In professional applications, you should check for broken references in your startup code, for this exact reason. See thread181-437632.)
You should put a development copy of the application on one of the failing workstations. Open it, open a module window, and check the references. I'll bet you see "Missing" there.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
When you start getting messages that these functions are not found, it's a symptom that you have a 'broken' Reference object further down the list. Some library later on is marked 'Missing'.
Usually, the symptom occurs when you start up the database, and in the runtime environment it just shuts down. You seem to be having less trouble than that for some reason, but I'm quite confident that this is the problem.
Unfortunately, in a runtime application you have to way to check the References list. (In professional applications, you should check for broken references in your startup code, for this exact reason. See thread181-437632.)
You should put a development copy of the application on one of the failing workstations. Open it, open a module window, and check the references. I'll bet you see "Missing" there.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
- Thread starter
- #9
Hi diamondsc
I had that exact same problem with runtime versions not being able to search only select from the combo list. I stumbeled upon your thread whilst searching for an answer.
We have Windows 2000 running and the development computers are running Access XP and all others are running XP runtime.
What I found out was that the runtime versions do not like the "limit to list" property set in the combo boxes. I just set that to no and the user of the runtime version was able to enter values in the combo box.
From here I wrote some code that searches the users entry and displays a error box if it is not in the list.
A bit late on the reply but I only found this thread yesterday.
Here is my code for the searching.
Public Function JobSearchReportsComboFix(JobNo As Integer, ComboID As Integer)
Dim iJobNo As Integer
Dim iCombo As Integer
Dim IsInQuery As Boolean
Dim Ans As Boolean
iJobNo = JobNo
iCombo = ComboID
'Is the job no valid. If not display error message and clear combo box
IsInQuery = IsNull(DLookup("[Job No]", "sqProjectRegisterAll", _
"[Job No] = " & iJobNo & ""
)
If (IsInQuery = True) Then
Ans = MsgBox("The Job No entered is not listed", vbOKOnly, "Error"
If (iCombo = 1) Then
Forms![fmReports]![sfReports]![JobNoPulldown1] = Null
ElseIf (iCombo = 2) Then
Forms![fmReports]![sfReports]![JobNoPulldown2] = Null
ElseIf (iCombo = 3) Then
Forms![fmReports]![sfReports]![JobNoPulldown3] = Null
End If
End If
End Function
Regards
Anthony Foster
I had that exact same problem with runtime versions not being able to search only select from the combo list. I stumbeled upon your thread whilst searching for an answer.
We have Windows 2000 running and the development computers are running Access XP and all others are running XP runtime.
What I found out was that the runtime versions do not like the "limit to list" property set in the combo boxes. I just set that to no and the user of the runtime version was able to enter values in the combo box.
From here I wrote some code that searches the users entry and displays a error box if it is not in the list.
A bit late on the reply but I only found this thread yesterday.
Here is my code for the searching.
Public Function JobSearchReportsComboFix(JobNo As Integer, ComboID As Integer)
Dim iJobNo As Integer
Dim iCombo As Integer
Dim IsInQuery As Boolean
Dim Ans As Boolean
iJobNo = JobNo
iCombo = ComboID
'Is the job no valid. If not display error message and clear combo box
IsInQuery = IsNull(DLookup("[Job No]", "sqProjectRegisterAll", _
"[Job No] = " & iJobNo & ""
)If (IsInQuery = True) Then
Ans = MsgBox("The Job No entered is not listed", vbOKOnly, "Error"
If (iCombo = 1) Then
Forms![fmReports]![sfReports]![JobNoPulldown1] = Null
ElseIf (iCombo = 2) Then
Forms![fmReports]![sfReports]![JobNoPulldown2] = Null
ElseIf (iCombo = 3) Then
Forms![fmReports]![sfReports]![JobNoPulldown3] = Null
End If
End If
End Function
Regards
Anthony Foster
- Status
Similar threads
- Locked
- Question