Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 529
  • Last Modified:

ODBC Timeout with Sorted Access Combo Box

I have encountered a very odd problem.

My client is using SQL Server Express 2014 with Access 2013. Everything works great except for one strange thing. I have a combo box on a form which is used for searching for the product selected in the combo box. The combo box is bound to the primary key field, ProductID, which is hidden. The combo box displays the ProductName which is an nvarchar(35) and is indexed. When I sort on ProductName in the combo box, and the user tries to edit data in the retrieved record, they get an ODBC Timeout error. When I simply remove the sort, making NO other changes, the search works perfectly, and the data can be edited as expected.

I use this identical technique on many other forms, based on many other tables, and it works beautifully.

Has anyone ever experienced this problem?
1 Solution
Jeffrey CoachmanCommented:
How many products are in the list?

The practical limit for list box items in Access is 1000.
You can change this in the options though...
screen...see if changing this value helps...

Dale FyeCommented:

I know you already know this, but the way you describe it above, the combo box you are using to search with is bound, is that what you meant?  

In my experience, the search controls (what ever they are) are generally unbound and have code in the afterupdate event to perform the record search, otherwise, you are simply changing the value of the bound control in the current record.

Helen FeddemaCommented:
From the question, I think this combo box is indeed used to select a new value for a field on the form (it is not a record selector combo box, which should be unbound).  But if not, here is some code for an unbound record selector combo box:
Private Sub cboSelect_AfterUpdate()
'Created by Helen Feddema 29-Apr-2011
'Last modified by Helen Feddema 29-Apr-2011

On Error GoTo ErrorHandler

   Dim strSearch As String

   'For text IDs
   strSearch = "[______ID] = " & Chr$(39) & Me.ActiveControl.Value _
      & Chr$(39)

   'For numeric IDs
   strSearch = "[______ID] = " & Me.ActiveControl.Value

   'Find the record that matches the control
   Me.Recordset.FindFirst strSearch

   Exit Sub

   MsgBox "Error No: " & Err.Number _
      & " in " & Me.ActiveControl.Name & " procedure; " _
      & "Description: " & Err.Description
   Resume ErrorHandlerExit

End Sub

Open in new window

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.


Access is using lazy loading for all situations, not only for forms. So if you assign a RowSource which directly loads data then you have to wait until the data is loaded before you can use the complete list. You see that behaviour if you try to use the scrollbar, it will not scroll correctly until the list is completely loaded which can take some time.

If you use an "ORDER BY" on server side Access has to wait even longer until the server loaded all the data and sorted it, so ORDER BY should not be added to a view on the server, always use it only on client side (like "SELECT All,My,Fields FROM MyView ORDER BY Whatever").

But the lazy loading behaviour can lead to a lock between different users working with the same form at the same time so that can also lead to a timeout (depending on other factors also like network speed, traffic, server speed and x more).
The best method to avoid that is to force Access to load the data quicker and that can simply be done in case of a combobox if you get the "ListCount" value. You could use that in the "GotFocus" event of the combobox like this:
Dim lngDummy as Long
lngDummy = Me.MyCombobox.ListCount

Open in new window

Now the combobox get's the data very quickly and normally there should be no timeout anymore (if you do not have other problems on the server).


TechMommyAuthor Commented:
I guess that I threw everyone of when I said that the combo box is "bound" to the primary key field. What I meant is that the bound column in the combo box is the primary key in the Products table. The combo box itself is UNBOUND and is only used to look up a record from the product table. Sorry for the confusion.

With that said, none of the solutions are applicable except Christian's. I will try it tonight and will report back with the results.
TechMommyAuthor Commented:
Thanks, Christian! That worked like a charm!
TechMommyAuthor Commented:
Thanks, Christian! That worked like a charm!
You're welcome. I had the same problem in my last project with Access and SQL Server with a combobox with xthousand entries used by many users at the same time. Nice side effect of using this is that the scroll bar works immediately and the user do not need to wait until the list is loaded completely.


TechMommyAuthor Commented:
Hi Christian,

I'm so glad the you encountered this problem and figured it out. I have been using Access since Access 1.1, and have created MANY client/server applications, but have never experienced this behavior before. I'm so glad that the fix was so painless!

Hi Alison,

in the good old days it was sometimes easier. The number of users was smaller, the amount of data also (OK, the network and computer speed, too...) but in the meantime any new version of Windows and Access adds layers over layers of code (like .NET, like security layers, network security protocol layers, new registry settings, new timeouts and many, many more). So Microsoft is proud to keep the speed of the computer the same since Access 1.1 because the computer gets more and more to do, not often really useful (i.e.: who really needs transparent window frames...?). I would bet that if you would try to do the same with an old Access and Windows version and an old server you would have the same result in a comparable amount of time and without timeout problems....;-)
I would really be interested in comparing the speed of a code which downloads data from a remote system when there's nothing in between of all these layers, only a little bit machine code on both sides.. That must be lightning fast if we compare the speed of a C64 with a modern x-core processor...and I remember that I was really impressed about the speed of my first machine code tries with C64 in 1987.

The world changes, we must, too...



Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now