Solved

Max Length of ADO Recordset Source property

Posted on 2004-08-18
6
2,166 Views
Last Modified: 2008-01-09
Does anyone know if there is a maximum length of the source property of an ado recordset.

If there is, what is the maximum length, and does anyone have a way of working around this.

I have a search form in which the user can enter criteria into a lot (40+) fields. Needless to say, the SQL query text can become quite long, and I seem to be having a problem if the query string is too long, am getting an error

"7874 : Microsoft Access can't find the object 'Recordset.'"

Thanks in advance for any assistance!
0
Comment
Question by:geefx
  • 3
  • 2
6 Comments
 
LVL 84
ID: 11839929
I don't know that this is your problem; I've seen some VERY long SQL String for ADO Recordsets. FWIW, i couldn't find any documnetation that explicitly spelled out the number of characters the ADO .Source property could have.

Could you post the portion of the code where you're setting/resetting and filling your recordset?
0
 
LVL 34

Expert Comment

by:flavo
ID: 11840058
Id say its the same as a query def (gueesing here) but that would be about 64k chars.

Are you sure that's the problem... does it work with a simple Select * from tblMyTable.... ???

Dave
0
 

Author Comment

by:geefx
ID: 11848159
Hmmm...not sure that is the problem at all, but seemed to be the only thing that it could be from my experimentation - if I shortened the sql string it seemed to work - it definitely wasn't an error in the sql string.

code portion:

  Dim rsx As ADODB.Recordset
    Set rsx = New ADODB.Recordset
    With rsx
        .ActiveConnection = CurrentProject.Connection
        .CursorType = adOpenKeyset
        .LockType = adLockOptimistic
        strSQLz = "LONG SQL STRING HERE"
        .Source = strSQLz
        .Open
        Set Me.sfmSearchAllResults.Form.Recordset = rsx
        .ActiveConnection = Nothing
    End With

The error occurs (with a long sql string only) with the statement
        Set Me.sfmSearchAllResults.Form.Recordset = rsx
The recordset is actually returned fine (so I guess that it is not the length of the ado .source property), but when I assign the recordset to the subform, that is when it fails.

It works fine if I use a "select * from products" type string.

Very Very strange!!!
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 84

Accepted Solution

by:
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 50 total points
ID: 11848393
Hmmm ... the max length of a .Recordsource is 2048 characters, I believe, and I'm pretty sure the Max Length of an ADO Recordset's .Source property is the same ... have you tried setting a breakpoint, copying the SQL being used to open the Recordset and pasting that into a query to make sure there are no troubles with it?

Here's a good MSDN article on binding forms to Recordsets:
http://support.microsoft.com/default.aspx?scid=kb;en-us;281998
0
 

Author Comment

by:geefx
ID: 11866266
the limit on the length of the sql string does appear to be 2048 chars as you say LSMConsulting - did a bit of playing around, and found it was fine for 2048, failed for 2049 characters in the sql string.

So based on that here is what I think is happening:
The ado recordset is returned with no problems, so there doesn't seem to be a limit on the size of the sql string here (at least not that I've hit)
When the recordset is assigned to the form, the source of the ADO recordset is assigned to the source of the form. So if this is > 2048 characters, then it fails, just as it would have if I had assigned the sql statement as the recordsource of the form itself.

Pretty annoying - don't know if there is a workaround for this??

LSMConsulting, have accepted your answer since you pointed me in the right direction.

Thanks for your help on this - very much appreciated - if you have any ideas on how to work around this, I'd love to hear them!
0
 
LVL 84
ID: 11868927
Two things come to mind:

1) Trim your sql as much as possible - for example, remove table names where possible:

SELECT tblCust.FName, tblCust.LName FROM tblCust

Instead, write this:
SELECT FName, LName FROM tblCust

2) Try writing your results to a temporary table, then you can do a SELECT * FROM YourTempTable" to populate your form/contro.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

It took me quite some time to sort out all the different properties of combo and list boxes available from Visual Basic at run-time. Not that the documentation is lacking: the help pages are quite thorough and well written. The problem was rather wh…
In a multiple monitor setup, if you don't want to use AutoCenter to position your popup forms, you have a problem: where will they appear?  Sometimes you may have an additional problem: where the devil did they go?  If you last had a popup form open…
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now