PDA

View Full Version : Using Autosuggest Lookup with Search box via Table View


ABC123

timnoakes
09-09-2009, 01:28 PM
Hello,

I've configured a grid using a view to combine fields into the same grid from two tables.

The problem I've got is Autosuggest lookup(in the search field) wont work on any of the fields from either table 1 or table 2.

This must be a limitation of grid components? Is there another way of combining to tables into one grid without having to use the grid linker?

Many Thanks

Tim

rleunis
09-09-2009, 03:27 PM
I'm using Oracle Express and autosuggest works on fields in a view. See pic. I have used this feature for one of the search fields from the view.

I've tested this with a field for which I created an index for the autosuggest field on the underlying table (of the view) and it also works on a field of the view for which I did not create an index in the underlyng table...

Mind you the autosuggest field is case sensitive so make sure you start entering with capital if your list starts with it.


!! Later after more testing:

I've noticed that it might certainly matter to define an index on the autosuggest field !
The first test on the field I did not create an index on, was actually the first entry in the view...But entries further on did NOT show up.
So: try creating an index on all the fields you are using for your autosuggest.
Let me know if you had success with that.

rleunis
09-09-2009, 03:33 PM
Is there another way of combining to tables into one grid without having to use the grid linker?


You can create a view as part of the grid definition (DBF DB) see PIC. (Under Grid > Query (DBF))

Using A SQL DB you can create a view there and base your grid on that.

Lance Gurd
09-09-2009, 03:59 PM
Or you could follow Selwyn's recent suggestion. Because hard disk's are cheap - just add fields to your parent table and forget all about relational databases.

rleunis
09-09-2009, 04:17 PM
Or you could follow Selwyn's recent suggestion. Because hard disk's are cheap - just add fields to your parent table and forget all about relational databases.

....!!!! Which recent suggestion of Selwyn? Where did he suggest this?

Are you or he serious?

Why using a relational DB then anyway? Just use one big XML file as your database...

timnoakes
09-09-2009, 05:49 PM
Hey Ron,

Firstly I started with a clean slate and recreated again what I previously attempted and wolah! it worked straight off.

So I compared my previous component and the new one and there were no differences, hmm just one of those things :(

The auto suggest in the search field works ok and isn't case sensitive.

Once again thankyou for your kind help.

Lance Gurd
09-10-2009, 03:19 AM
....!!!! Which recent suggestion of Selwyn? Where did he suggest this?

Are you or he serious?

Why using a relational DB then anyway? Just use one big XML file as your database...

I am afraid I think Selwyn was serious, this is the e-mail interchange between us

First a reply from Selwyn to what I considered a bug

>Lance
>
>I have been contemplating your bug report about the edit-combo for the
>situation where you display a different value than you return.
>
>You reported that there was a bug because when you typed into the
>control, the value that you typed was filtering the display based by
>search in the return value fields and not the display value fields.
>
>After thinking about this for a long time, I have concluded that we do
>NOT consider this to be a bug.
>
>This is what you should do:
>
>Say that wanted to define the edit-combo to display: Lastname, and
>return: customer_id
>
>You should define the edit-combo for the 'Lastname' field.
>You should have a customer_id field on your grid, but you can set it's
>control type to "hidden"
>
>You should change the edit combo to display: "Lastname", return:
>"Lastname" and fill-in: customer_id (the hidden field)
>
>then, when you interact with the edit-combo, typing will filter the
>list as you expect.
>
>when you make a selection, it will fill in the value into lastname
>(which you don't care about), but it will also fill in the hidden
>customer_id field with the customer_id value (which is what you want)


To which I replied and got RED Replies from Selwyn

>Selwyn,
>
>Doesn't that negate the, sometimes, whole purpose of a look-up?

no, i don't think that it does.




>How would you do this in Alphasports invoice items table for instance
>where the product_id is stored but the product description is shown,
>you would either have to add another field to the table for the product
>description or add a calculated field to the grid, both adding overhead
>to the table!

you would add another field to the table. when 1 terrabyte disks cost $60, i would not worry too much about adding an additional field to the table.


I am now flattening and enlarging my tables to get edit-combos to work in look-ups how they work on the desktop, I love the way V10 works but find this a big stumbling block.

Flat large tables may take up more disk space and slow things down marginally but coding them is a lot easier :p

rleunis
09-10-2009, 05:24 PM
I agree (if I understand your issue correctly..) that the edit combo feature should facitate a field (computed) to enter the data (based on your selected attributes) which then automatically fills the field with the id value the return field needs...

Adding a field in your table which makes this feature works jeopardises relational DB relational / normalisation standards.

Interesting discussion...

Most IDE's do not offer this Alpha combo feature.
Usually it's just a dropdown only.

So maybe experience is needed to make this more mature...