Dynamic Queries with field lists.

Why do you need a field list - you're not running a fat client connection are you?

Why do you need a field list - you're not running a fat client connection are you?

I'd rather not (and usually don't do). But this customer's end customers tend to use it. The application is still client/server being modernized stepwise to OERA with AppServer - but currently there is only little AppServer code. So I must admit, it's understandable that at many end customer site's there is a tendency to run that on the client.

In this case, all I can think is to have a set of appropriately structured static queries in something persistent, and then use their handles to open and manipulate them as needed.

In this case, all I can think is to have a set of appropriately structured static queries in something persistent, and then use their handles to open and manipulate them as needed.

Yeah

It's going to get dirty, because we will also need to specify the same field list in the ATTACH-DATA-SOURCE method of a ProDataset buffer. And there seems to be no way to query the fields from above, so we need to keep those lists twice. Bad.

FWIW, the other option is of course to limit the fields in the temp-table you are sending across.

I am sure you considered this but in some cases it might be an option.

We always use that option, as all our temp-tables are dynamic so we always create only the fields that we actually want to send across.

So who needs fields lists?

So who needs fields lists?

As written in my original post. The beauty of appserver code is that you CAN run it on the client. When there is not a lot AppSErver code yet, it's difficult to argue that every end customer site uses the AppServer immediately (although you know, I would prefer that). And when the LAN network bandwidth is an issue the field list between the client and the DB server may get very relevant. Although if I'm not completely mistaking, that Oracle data server uses field lists to optimize reads as well.

I fully agree that this is not an issue for code that already runs on the AppServer. But for this customer, it's right now still future, not present.

But when Peter, Tim and Gerd don't know a solution, I guess there is none and I didn't have apples on my eyes when I was reading the docs this morning.

Try PSC Tech Support and see if there's something "not in the docs" you can do.

This works for me with 10.1C02

DEF VAR hq AS HANDLE.
CREATE QUERY hq.
hq:SET-BUFFERS(BUFFER customer:handle).

hq:QUERY-PREPARE("for each customer fields(cust-no)").
DEF VAR i as inte.
hq:QUERY-OPEN().
DO WHILE hq:GET-NEXT() i = 1 TO 5:
   MESSAGE BUFFER customer::cust-no
           /* BUFFER customer::name*/ /* -> complain with error 8826 */
      VIEW-AS ALERT-BOX.
END.

Got (very quick) response from tech support - thank you guys.

Looks like there is a difference between full dynamic queries and static queries that you open dynamically, this works:

CREATE QUERY qh.

qh:SET-BUFFERS(BUFFER customer:HANDLE).

qh:QUERY-PREPARE("FOR EACH customer FIELDS (CustNum Name City ) WHERE custnum

But with a statically defined query it doesn't:

QUERY qryCustomer:QUERY-PREPARE("FOR EACH customer FIELDS (CustNum Name City ) WHERE custnum

Throws an error at me:

FIELDS/EXCEPT belong on DEFINE QUERY, not on OPEN QUERY. (3638)

While I can now workaround that (using the DYNAMIC property of a widget handle for the first time in the real world), this is another useless case of inconsistency in the ABL.

Exactly. Giving you the answer points, share them in mind with tech support

Just got another response from tech support, didn't wanna keep that hidden from the forum:

1.       You are using a dataserver.

2.       You have especially bad network performance in a particular situation.

3.       You know for a fact that no uses of non- FIELDS fields can come up.