Re: Ctrl+F in MsAccess table is very slow

I think Access not knowing if the server side fields have indexes is
common in both tables and views. Are you viewing the table using a form
or the tables?

What I often do is make a form as a sort of search tool, with a text
input box, and maybe a combo box to select the field I am searching in
then you can do something like:

sSearchItem = textBox.value
sSearchField = comboBox.value
sSQL = "SELECT * FROM yourTable WHERE " + sSearchFeild + " LIKE '" + _
sSearchItem = "';"

set recordSet = currentDB.openrecordset (sSQL)

Then you can put the results in a list box

Set list.Recordset = recordSet

This should be a bit faster than cntrl-F, not sure if it is appropriate
for the project your working on, but I always seem to be making some
kinda search form for my projects.

Arnaud Lesauvage wrote:
> David Gardner a écrit :
>> Try this with and without the Declare/Fetch option checked. Also this
>> may be a situation where you may have an index on your varchar field,
>> yet Access doesn't know about it.
>>
>> Also what datatype does Access think the field is? I have run into
>> problems where Access will think the text datatype is a Memo field (FAQ
>> 6.5 & 6.6). While on the subject of Access being weird is either your
>> index field or the codelocalite field declared as int8(bigint)?
>
> Hi David,
>
> Turning on or of UseDeclareFetch apparently makes no difference.
> But you are right that the field is indexed and that Access doesn't know
> about it (probably because the linked table is a view, not a real table ?).
>
> Apart from that, the field is a varchar and Access sees it as such, and
> codelocalite is an int4 field, so I think everything is fine here.
>
> Regards,
> --
> Arnaud
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>