Oracle, one week later

Question

coming from an msaccess point of view
maybe better to ask this question in another forum but i think you guys are interested in the problems that a developer has coming from access to oracle.
been using ocracle for almost a week now and i have the following thoughts.
after installing and unlocking the sample db start learning htmldb.
pl/sql will be something like vba, it will contain the program logic that htmldb can't.
java can wait until htmldb and pl/sql have been mastered.
bit surprised that their no visual way to create the web pages. creating pages using htmldb works okay and i'm sure that once i get the hang of it i'll be able to create pages really fast but right now it seems like its a slower way than the way we create "forms" in msaccess.
now on to my problem.
the simpilifed problem.
i created a blank page with the wizard.
i created four regions, but for this simpilifed problem we are only concerned with the region "employees"
inside the region "employees" is 3 buttons and a "list box"
the list box should be comprised of three columns from the employees table
column 1 is employee_id, column 2 last_name, column 3 first_name
the problem is that i'm unable to create a "list box".
i thought a select list was what i wanted but i see now that it's not.
so how am i supposed to (in msaccess terms) create a listbox that uses an sql statement.
i'm leaning toward the idea that a region is not "something" like a option group box in msaccess.

Answer 1

Have you tried a multiselect list? A list box would need to be added as an "Item" in a region.
As far as the SQL behind anything that is a list of values, you will need a display_value and a return_value in your query. Obviously, the display value is what you see in your list and the return value is the value that will be passed by that box (:P#_MY_LIST_BOX_VALUE = return_value).
So if I wanted to represent all 3 columns I would set it up the query in the LOV definition like this:
select employee_id || ' ' || last_name || ' ' || first_name display_value, employee_id return_value from employees
Now, when someone selects an employee with an employee_id of 1 it sets :#_MY_LIST_BOX_VALUE = 1. You can obviously play with the values these return, I just lean toward keeping them digits/ids/keys.
If you create you LOV as a shared component you can play with the different types of boxes without rewriting your query for each.
Message was edited by:
moody