| Subject |
Re: function form_onNavigate(nWorkArea) |
| From |
roy price <royprice@royprice.name> |
| Date |
Tue, 11 May 2021 08:33:51 +1000 |
| Newsgroups |
dbase.getting-started |
On 10/05/2021 11:53 pm, Mervyn Bick wrote:
> On 2021/05/10 15:24, Mervyn Bick wrote:
>
>>> The field is indexed and named "rec". I deleted the index saved the
>>> table, and then recreated it, to no avail.
>>
>> What is the index expression used to create the index?
>>
>>> I'm confused as to why the syntax for a character field works for
>>> records containing numbers that are over 1000, but not those under
>>> 1000. Should it not work at all?
>>
>> It's working for four character values because these don't need
>> padding to fill the field. There is, therefore, no problem finding
>> the corresponding value in the second table.
>>
>> It's not working for 1, 2 and 3 character values because the rec
>> fields in the two tables are not padded in exactly the same way.
>
> Some more thoughts on this. The contents of the rec field itself should
> not be padded at all. If you have padded the contents it can be removed
> quite easily.
>
> use cactusaa
> replace all rec with ltrim(rec)
> use
>
> use cactusaatext
> replace all rec with ltrim(rec)
> use
>
> Recreate the index
>
> use cactusaa exclu
> index on right(space(4)+trim(rec),4) tag rec //or whatever you named the
> index
> use
>
> use cactusaatext exclu
> index on right(space(4)+trim(rec),4) tag rec //or whatever you named the
> index
> use
>
> Mervyn.
Hello Mervyn,
Mystery solved....
In setting up different directories for testing , (Causing confusion) my
Form's SQL for that file was selecting the wrong directory, where the
table still had the character field.
Changing to the correct directory, makes the relationship works to bring
up the correct record as it did in the test Form.
I found my mistake when I changed one of the records, but the change was
not shown when running the form.
Apologies for my wasting your time.
Regards
Roy Price
|
|