as per the title,
whats the best way to keep focus on the current record?

changing index will move of the current record.

bookmark wont work
and neither will record number.

any ideas.

cheers

Aaron Taylor <service@jme.com.au> wrote on Thu, 25 May 2006 21:46:12 -0400

>as per the title,
>whats the best way to keep focus on the current record?
>
>changing index will move of the current record.
>
>bookmark wont work
>and neither will record number.
>
>any ideas.
>
>cheers
>
Aaron


I would simply save the key of the record and do a Locate.


Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

what if theres more than 1 record the same ?



Jeff Cook <jeffc@aspect.co.nz> wrote:

Aaron Taylor <service@jme.com.au> wrote on Thu, 25 May 2006 21:46:12 -0400

>as per the title,
>whats the best way to keep focus on the current record?
>
>changing index will move of the current record.
>
>bookmark wont work
>and neither will record number.
>
>any ideas.
>
>cheers
>
Aaron


I would simply save the key of the record and do a Locate.


Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Hi Aaron,

> what if theres more than 1 record the same ?

That should never be the case. Every record in every table should have some
unique identifier otherwise how would you ever know you were
updating/deleting the correct one?

--
Best regards

Steve

"Aaron Taylor" <service@jme.com.au> wrote in message
news:963A21D4-5327-4101-8348-3F78E4C2C26A@news.elevatesoft.com...
> what if theres more than 1 record the same ?

i dont mean exactly the same
but if you have 10 fields 5 of wich are indexed
you may have records where the data is the same in all indexed fields.

should i put an autoinc field in, and monitor that as the record position ?



"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote:

Hi Aaron,

> what if theres more than 1 record the same ?

That should never be the case. Every record in every table should have some
unique identifier otherwise how would you ever know you were
updating/deleting the correct one?

--
Best regards

Steve

"Aaron Taylor" <service@jme.com.au> wrote in message
news:963A21D4-5327-4101-8348-3F78E4C2C26A@news.elevatesoft.com...
> what if theres more than 1 record the same ?

"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote on Fri, 26 May 2006 14:09:47 +1000

>Hi Aaron,
>
>> what if theres more than 1 record the same ?
>
>That should never be the case. Every record in every table should have some
>unique identifier otherwise how would you ever know you were
>updating/deleting the correct one?
>
>--
Steve


Here! Here!  (That's why I said to save the key!)

Just add an autoinc to the table and put an index on it and all will be honky-dory and no existing logic should be broken.

Cheers and a merry weekend!


Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Aaron Taylor <service@jme.com.au> wrote on Fri, 26 May 2006 01:09:05 -0400

>i dont mean exactly the same
>but if you have 10 fields 5 of wich are indexed
>you may have records where the data is the same in all indexed fields.
>
>should i put an autoinc field in, and monitor that as the record position ?
>
>
>
>
Aaron


The quick answer is "Yes".   If your really, really, really don't want to change your table structure, remember that you can use a Locate on non indexed fields, so it would still be pretty quick (and ugly!) because of the 5 indexed fields.

Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Hi Jeff,

> Cheers and a merry weekend!

You too mate!

A side comment for Aaron ..

The primary key must uniquely identify a record and whilst it can be a
concatenation of several data columns, this is IMO not good practice as a
derived key's dependency on table data can cause major problems down the
track. I use an independently generated primary key for every record in
every table I have ever created, depending on the actual application, these
may be Autoincs (works very well in DBISAM), keys served from a key manager,
or GUIDs. In the olden days, it was taught that primary keys should be a
small as possible, as this improved the performance of SQL key operations on
the DBs of the day. This is probably not as important now, but IMO is still
a good design habit.

--
Best regards

Steve

"Jeff Cook" <jeffc@aspect.co.nz> wrote in message
news:24C3A821-0D60-44E7-99D6-09CA079903B3@news.elevatesoft.com...
> "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote on Fri, 26 May 2006
> 14:09:47 +1000
>
>>Hi Aaron,
>>
>>> what if theres more than 1 record the same ?
>>
>>That should never be the case. Every record in every table should have
>>some
>>unique identifier otherwise how would you ever know you were
>>updating/deleting the correct one?
>>
>>--
> Steve
>
>
> Here! Here! (That's why I said to save the key!)
>
> Just add an autoinc to the table and put an index on it and all will be
> honky-dory and no existing logic should be broken.
>
> Cheers and a merry weekend!
>
>
> Jeff
> --
> Jeff Cook
> Aspect Systems Ltd
> Phone: +64-9-424 5388
> Skype: jeffcooknz
> www.aspect.co.nz
>
>
>
>

Aaron


Just to expand on what Jeff said. Each record should have a primary key - something which makes it possible to uniquely identify the record. This may be a single field or a collection of fields. If you don't have something like that already then yes add an autoinc as the primary key, if you do then simply get those values before altering the index and do a Locate afterwards.

If you're using persistent fields make sure all of the fields you need for the Locate are in the list otherwise it won't work.

Roy Lambert

thankyou to all