ebrandt:
Before I embarked on this method I just wanted to confirm that it was possible:
All the value lists I have created so far have mostly been relationship based, this has worked well.
I have been trying to work through an issue related to portal elements at the cell level that is not possible.
In my related portal lines items I will have a field called item_class (A, B or C in a combobox) and a field item_code (where I want a dynamic Type Ahead Value list.
I also have three tables: table1, table2, table3
I want to load all the values from either table1, table2 or table3 into the dynamic value list that I will have assigned to the item_code, based on the selection made in the combobox assigned to the item_class field.
I will do the research for building these Value Lists based on a argument. I just wanted to make sure that I would not have any issues with this being in a portal.
I figured I would run this method (populate the value list), based on the (OnFocusGained) event of the Item_Code field.
Hi Erich –
I’m going to take 25 steps backwards here (a trick I’ve become known to do on other forums), and bring the question back to an inquiry into the structural design of this database. The replies that followed your original post have been bookmarked for my further study – the question of how to achieve this in javascript code is just way over my head right now in terms of my progress in learning Servoy! So apart from the question of what code you can use as your “sledgehammer” to build this value list, I’m wondering whether - if the blocks of wood are just stacked a bit differently - maybe you do not need any special tools at all to build the list.
In your description you refer to 3 tables as “Table 1, Table 2 and Table 3”, from which you wish to populate a dynamic value list, based upon the selection of A, B, or C in the item_class field. If we take it out of generic “Table 1” type of names, what are the actual entities these tables represent?
It is obvious from your screenshot that A, B, and C in your description refer to the “Inventory Sales”, “Misc Parts Accessory Sales” and “Listed Parts Sales”. Sounds like the items in the three tables from which the item_code list would be derived are all lists of things sold? There is a field in each of these tables called “item_code”? The three tables probably share other attributes such as, for example, price, qty_per_unit, unit_type (i.e., “carton” or “piece”), maybe inventory restocking level, quantity discount levels, etc.?
I have almost always found that when I discover a need to build a value list from two or more tables, a re-examination of the structure shows that the attributes of those tables are almost if not exactly the same, perhaps with the exception of one or more “status” or “type” attributes. Therefore it is possible the tables in question do not really represent distinct entities within the overall framework of the solution, but rather are sub-classes within a single entity, and can be combined into one table.
I wonder if your three tables can similarly be combined into one, with an item_class column that, in each record, would hold one of the three “Sales” types in your combobox. If this description makes sense at all regarding the solution you are working on, you could then use a simple relational value list based on a match between the item_class field the “Equipment Information” line-items table in the portal and the newly-combined single Products (or Equipment or whatever) table.
My apologies in advance if all of this is hopelessly obvious and perhaps does not pertain at all to your solution. Looking at your screenshot it sure looks like a well-considered design. I’m only “thinking out loud” in the same type of process I make myself go through when I find myself wondering how to perform what I think of as “acrobatic coding” to achieve the compiling of multi-tabular data into one column in another table. It sometimes helps to take it back to a question of structure, on a very basic level, one more tme before proceeding. So, I certainly am not asking you to defend or explain the structure you have designed to in response to this post … there sometimes are also very good reasons for keeping similar entities stored in separate tables, rather than lumping them together. (For example, being that this is Servoy, they could be 3 tables on 3 different back ends from 3 other solutions over which you have no structural control…)
just some food for thought,
kazar