Hi,
Maybe is the following expected behaviour but I was wondering why it is possible for a developer to make a mistake like this.
In a static temp-table you can NOT create a field 'status', Progress does not allow that!
But if you create a dynamic temp-table there is no problem to add a field 'status' (add-new-field).
Also can you fill that field with data, that's no problem.
You can even use that data when you work with buffer:buffer-field('status');buffer-value.
But if you want to use it like buffer::status you will get an Progress Error.
I can understand this from a compilers point of view but it's confusing.
The greater problem is that you can't use a hbuffer:find-first or a dynamic query-phrase with a selection on 'status'.
That will always give a run-time error
Like I said, I can understand why the compiler does not complain about these dynamic created fields.
But why Progress allowes you that you can create those protected-fields (like 'status') and let you fill them with data and even let you use those values in (some) statements but doesn't let you select some records based on that field @run-time is strange to me.
Is that expected behaviour?
Should Progress not better warn a developer if he/she creates a protected field (like 'status' in a temp-table (@compile or @run-time).
Or can Progress adjust the query-engine so these fields can be used (all fields that can be created should be allowed in queries I guess)
Or is there already some possibility to use those fields in a query?
I found that problem when I was developing a program that will generate a dataset and buffers based on some file that was provided to that program.
In that file these is a field that is called 'status' so it was created fine but at some point I hit this query problem.
If it's expected behaviour that some fields can not be used this way I will need to add some transformation for those fields because I never know what can come in. Is there some list of what fields that are not allowed to use this way?
Regards
Didier
Noticed this as well. It is one of the reasons I use Hungarian notation for temp-table fields and vars. At a client, the software had a field in one of the tables called 'dataset'. All went well, until DATASET became a keyword.
Seens this issue has been around for longer in some form or another. See also knowledgebase.progress.com/.../000031232 .
I think this is a defect.
Either dynamic temp-tables should disallow field names that the query engine can't handle, or the query engine should be enhanced that it *can* handle these field names. (Maybe it can be tweaked so qualified field names can always be handled, meaning "mytable.status" will work where "status" fails ?)
Yes but the problem is that I create all TT's and fields dynamically and I use the names that are provided in the input file.
I have no control over those names so the only thing I could do to prevent this problem is use some prefix/suffix to all those fields.
But better would be that Progress could handle these fields in there query-engine (I guess).
I found it strange and was wondering is it's a defect or not so I reported it.
@Frank: the link doesn't work but I thought that someone had already bumped into this problem but still not sure if it's a defect or not (we both think it is)
Link should work now. I blame that on forum software weirdness. And the KB article also shows an (old) defect number.
Yep, is the same problem
You can create <whatever> fieldname with add-new-field in a dynamic TT.
You can fill and use them but you can't select on them in a query...
KB is from 2015 so I guess it will not be solved (and/or looked at)
did you try the -k startup and reference a keyword forget list?
No I did not (but I'm not sure if that's a good idea - don't know)
I do not like doing this but sometimes you have no choice. We integrate with a 3rd party eCommerce site and they have a process that runs and syncs up web orders to the Openedge DB (sql table) and one of the fields is named "status". This causes us all kinds of issues but they would not change the field name. We either had to use -k or find another partner.
Or if it's a dynamic source use a standard prefix/suffix that you can code everywhere when needed (also not ideal but I think it's better then using that -k parameter - not sure)