| Subject | Re: Can someone explain to me what's the best way to do this? |
|---|---|
| Author | Svein Erling Tysvær |
| Post date | 2004-11-30T12:17:57Z |
Hi Andrew!
upgrading from Oracle are likely to fall into different pitfalls than
those that have used Excel sheets for their "database".
Secondly, using locate is generally a bad idea, LIKE can be used in
some cases, but is likely to not use any index (in your case an index
could be used, whereas if you used a parameter rather than a constant,
no index would be used), whereas STARTING [WITH] normally uses an
index if available.
scroll through all of them.
cursors and queries (for use in selecting datasets), but may fake that
it has a table object. Basically, it allows users to do silly things
and tries to convert it into intelligent queries. Using other
components, I would try to avoid table objects unless the table is
really small.
and a query if bidirectional access is neccessary.
HTH,
Set
> Hi all,Well, I suggest you first tell us what you are upgrading from, those
>
> I did some searches on the NG and I couldn't find any topic for
> this... so, sorry if this seems silly, but working with development
> machines everything seems nice (but very unreal) and I don't want to
> blow it with my customers (that will crucify me if I upgrade their
> app to something slugish) :-).
>
> I have migrated tables from another app to FB and I have made a
> extra column for names (no accent chars, all uppercase) and I've
> indexed it. Now, how can I use these indexes to do fast searches?
>
> Do I use
>
> table.locate(...)
> or
> select a,b,c from names like 'MICHAEL%'
upgrading from Oracle are likely to fall into different pitfalls than
those that have used Excel sheets for their "database".
Secondly, using locate is generally a bad idea, LIKE can be used in
some cases, but is likely to not use any index (in your case an index
could be used, whereas if you used a parameter rather than a constant,
no index would be used), whereas STARTING [WITH] normally uses an
index if available.
> These tables tend to have something around 50K-250K rows of names onNavigate through some of them sounds OK, just avoid letting your users
> them and are "searched" very much by a lot of people. Names are seen
> on a grid on a form so they can navigate through some of them.
scroll through all of them.
> Does table.locate(...) does a search and drags all the records byI think that will vary with your choice of tool. IBObjects only has
> wire to the workstation untill the position of this 'MICHAEL%' guy?
> Or does a select make it work faster?
cursors and queries (for use in selecting datasets), but may fake that
it has a table object. Basically, it allows users to do silly things
and tries to convert it into intelligent queries. Using other
components, I would try to avoid table objects unless the table is
really small.
> Is there another (aka better) way to do these kind of searches?You ought to use SELECT, using a cursor if unidirectional access is OK
and a query if bidirectional access is neccessary.
> Using FB 1.5.1.Good choice!
HTH,
Set