Solved

Max Length of ADO Recordset Source property

Posted on 2004-08-18
6
2,232 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
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

 
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

Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A simple tool to export all objects of two Access files as text and compare it with Meld, a free diff tool.
It’s been over a month into 2017, and there is already a sophisticated Gmail phishing email making it rounds. New techniques and tactics, have given hackers a way to authentically impersonate your contacts.How it Works The attack works by targeti…
Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…
With Microsoft Access, learn how to specify relationships between tables and set various options on the relationship. Add the tables: Create the relationship: Decide if you’re going to set referential integrity: Decide if you want cascade upda…

785 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