Anyone else sick of inputting field lookups in multiple places?

Scriptcase 9 General
#1

I may be doing something wrong, but I’m forever going back to applications with lookup values. There are so many places in the IDE to add the lookups (Grid, Groupby, Search, etc) that I invariably miss one and only discover it in later testing.

I reckon if you save 80% of the time with Scriptcase, I must give back AT LEAST 10%-20% dealing with the inconsistencies this causes.

I’m used to a proper data dictionary where you define this stuff once and then it gets applied everywhere (Unless you override). As far as I can tell the Scriptcase data dictionary is just for translation and has little to do with the data itself.

Does anyone know of a way to align the lookups automatically?

#2

you should familiarize yourself with the internal libraries if you have not already done so, set the redundant procedures for this place once and for all, unless I understand you,

#3

Sorry, I’m not sure what you mean?

I’m very familiar with the internal libraries and there is nothing to synchronise lookups

DO you mean the Data Dictionary?
That does size and other parameters, but not the lookup condition.

#4

You’re quite right, so I did not understand you, my apologies, it’s true that I do not use the Data Dictionary too much,
but for the lookup, often sub-queries, or manual lookups are dependent on other parameters, I prefer to handle them on a case by case basis

#5

That’s the problem… I prefer the opposite because 99% of the time I don’t want or need to change them. So my way of working would be to set them all the same based on the main field settings and only change the 1% that are different. in the summary, search, etc. (A bit like the way the express edit works)

I’m not arguing that they should always be the same, so agree you will need to change things sometimes, but I would argue that (With the possible exception of search) they should ALMOST always be common. (otherwise you confuse the user)

#6

I know what ar you talking about, but I find that the grid and its form, has a kind of limited lookup engine, and there are are very different:
Grid: returns 1 columns (description), where using the table id filter. If you use multiple columns, it made a concat or of it.
Form: returns 2 columns (id and description), with no filter most of the time. Same behavior on multiple columns. (concat)

Having a LOT of issues using subquerys, custom (sql) function calls, for complex lookups, I prefer to build a regular old sql view, and use the view as source of the lookup. The view can be as simple or complex as you wish, and the lookup will work flawlessly.

The output of the view must be only 2 columns: the ID and the visible text or description. Later on, if you must concat a nuew field or change a description member field, just change the view, not the all the lookup tables of that particular view. Give a try.

#7

Hmm… I think that might be better than nothing and I like the idea of a central lookup. I’ll certainly give it a try. Excellent, thank you.

I think I will still have the problem of needing to update many fields, but it will at least remove some of the typing errors and once setup will be an easy way of keeping everything in-synch if you want to change anything.

Wouldn’t it be good if you could automatically tell the IDE that every time this database field is accessed then use this view? That way you get your very nice solution plus remove the pain of keying a link to it everywhere.

#8

to call a view without having to depend on a specific view name in the query, I usually use a global instead of the name or complement (ex: view[gloref]), not to to be problematic however it is necessary to define a name by default by launching the application which can be ‘’ at the beginning.
like this:
"SELECT if([valrem] in(select val_txt_a from val_not),(select val_txt_d from val_not where val_txt_a = [valrem]),[valrem])
FROM notes_eac[val] "
in mysql