Issues with SEEK on Split Database there has to be a better way.

[zmbd]

OK,
This drives me nuts... I spend all of this time in development. Typically I start out with an all-in-one database. Creating the forms and so forth is all quite straight forward (well, now :-) ).
While I doing all of the development, and for those little databases I use at the desktop, I use the SEEK method on my indexed tables and all is well...

then, I split the database.

Of course, everywhere I've used the SEEK method on a table that is now linked, now fails. So typically I use one of the three options I’ve found:
1) OpenDatabase method on the back end
2) Re-write the code to use the Findfirst method
3) Re-write the code to use one or more of the domain functions such as Dcount/Dlookup etc...

Although I prefer the fist option, I've a few issues:
1) Password protected backends. The password is in the code... just waiting for someone to back engineer the code to pull it out.
2) it just seems so, well, redundant to have both linked tables to the backend so that the bound forms will work and then to have to open the backend on a recordset so that I can use the seek method and it doubles the number of connections to the backend.
3) It causes all sorts of other issues if a second user is also trying to work within the same table at the same time (which happens more often than I like) and starts searching for a record. Frankly, I end-up with option 2 or 3 just to get around the table conflict.

What am I missing here?

[TheSmileyCoder]

I have always used .FindFirst and its suited my needs just fine so far. Reading a bit up on Seek (As I have never used it) I see that it might take greater advantage of indexes then the FindFirst. However I have not yet run into a issue where the performance of FindFirst has not been satisfactory.

[NeoPa]

As Smiley says, I believe DAO typically expects to use SEEK when dealing with tables directly. I wasn't aware this did not extend to use on linked tables. That's something I've just learned from you. However, Using Find... instead should be as efficient as you could do anyway in the circumstances. If you want to use linked tables, and I suggest you should, then simply bear in mind that you need to develop in future with that limitation in mind. Tables can always be opened as a query even when local, so you should always be able to use that approach.

Simple rule, only ever use SEEK when dealing with tables that will always be local. In my experience, these are almost always very small and won't benefit from any difference in performance, but avoid using it for BE tables.