Search results

If I recall correct, an index, in classic sence, was a copy of the actual column(s) that was loaded into memory to spead up searches, sorting and dataretrieval. The index was searched first, if/when a match was found in the index, then the relevant/required/specified columns of that row was read...

You said so yourself - in the interface, you could run the query by doubleclicking it -> Access can see the parameters, and resolve them. When you open a recordset based on a parameterized query, it's not Access doing the job, you're querying a Jet database through either ADO or DAO. Neither...

The method I'm using (both with ADO and DAO) resolves parameters from forms dynamically. The construct for each prm in .parameters prm.value = eval(prm.name) next prmloops through (or is at least supposed to loop through) each parameter in the query. Then for each of those...

Well, Access can see the parameters, but neither ADO nor DAO can ;) For ADO, if you're sure you're going to use 2002 and later version, you could do something like thisdim cmd as adodb.command dim prm as adodb.parameter dim rs as adodb.recordset...

No feelings involved :) The upper half of that picture is wrong. Jet will not bring all 10k records over to the client as long as you know what you're doing. With proper indexing, Jet will bring only the 15 records required. Se for instance the thread "Does a filtered mdb recordset still bring...

This query seems to be based on another query. That's probably where you have a parameter that you haven't resolved. See, when firing a query from the interface, it will resolve parameters from forms, but when you wish to open them through ADO/DAO, you need to resolve the parameters.

KenHigg, I'm looking at the illustration in your link (post #9), which is wrong. As long as you know what you're doing (indices), Jet will return 15 records, not the whole table.

Is there any need for primary key? The purpose of a primary key, is to ensure each row is unique (no dupes), so that one may address each row individually. If you need to ensure that no two rows are duplicate, and/or you need to be able to address one specific row (to edit or delete), then...

Not that I know, cause I've never gotten to like that FileSearch thingie, but I thought it was implemented first in the xp/2002 version (and, fortunately, removed in the 2007 version). One place with a bit of code, comparision etc, is Douglas Steeles article http://advisor.com/doc/16279, then...

Not relating to the solution or later suggestions, but the below statement from the first reply... > I'm not sure where you intended to go with this code, but to clarify, the .Execute member of the ADODB Connection object is for the execution of an Action query, not for the return of data to a...

Followup on what Pat Hartman mentions. If you were to execute the query on an ADO connection, you could fetch the last identity (autonumber) using the same connection, something along the following lines: ' dynamic SQL myconn.execute "<TheSql>", , adCmdText + adExecuteNoRecords ' query/SP...

I'm not going to write your program, that you'll have to do yourself ;) But post your current code, be a bit explicit about what it does, what it doesn't, what happens, what should happen..., and someone will probably have a go at it. Do post the code within the thread, please, and inside [...

Well, the most obvious question is, does the queries have parameters? If the answer is yes, then they need to be resolved. While the DoCmd.Thingies and perhaps some other methods are able to fetch stuff from open forms etc, the OpenRecordset method isn't. Here's some air code supposed to...

This sounds like corruption, but first... If you use some methods available in 2003 that isn't implemented in 2000, I think you should get some compile or runtime error, but the "sorry for the inconvenience" message would normally have other causes (like for instance corruption). But, you...

Check out http://support.microsoft.com/kb/278973 or http://support.microsoft.com/kb/295646/EN-US/

You are doing several "no-nos" here. One is implicit instantiation of Excel through Dim xl as new excel application, should be Dim xl as Excel.Application set xl = New Excel.Application or instantiate through CreateObject Dim xl as Excel.Application set xl = CreateObject("Excel.Application")...

? rst.NAME will give you "the name" of the recordset, aka the source (here the select statement). Compare with a field name in stead. If UCase(str_DataSet) = UCase(rst.fields("NAME")) Then Better, apply the condition in the where clause, then check for existing records ... WHERE...

I'm hopeless with SQL, so I won't even try ;) There are some articles, here is one http://msdn2.microsoft.com/en-us/library/Aa140015(office.10).aspx, which also links to two other in the same series (at the bottom of the article) When Jet 4.0 was introduced around mid 1999, I think, there were...

You're specifying adCmdTable, but the CommandType you're actually using here, is adCmdText. What you could be using, is just using the name of the query as CommandText, and adCmdStoredProc as CommandType. How does the SQL look? Are you per chance using wildcard? If so, remeber that ADO...

I don't know, but some thoughts. I'd first remove any reserved words (see http://support.microsoft.com/kb/321266/EN-US/ -> "close"), and see if that was enough. If not, I think I'd try replacing the [brackets] around the subquery with (parens), perhaps also removing the dot (.), as I think...