Dynamic Temp-table

Rajat Sharma

Rajat Sharma

Member
Hello everyone,

I studied about dynamic temp-table and visualized the benefits that we can get from it. i tried the simplest scenario of dynamic temp-table but facing some issues ex:

Code: 
def var qh as handle.
create temp-table qh.

find customer where customer.custnum = 1.
   if available customer
   then do:
      qh:add-new-field('c-num','integer').
      qh:add-new-field('c-name','char').
   end.
  else
  qh:add-new-field('available','log').

  qh:temp-table-prepare('prac').
1. If i am creating the write dynamic temp-table then how could i assign values because at compile time compiler doesn't find 'prac' reference.

Best Regards!
Rajat.
 
Last edited by a moderator:
Usually you either use the buffer-value attribute to the field

Code: 
qh:buffer-field ( 'field-name' ):buffer-value = 'xyz'

or the short cut syntax

Code: 
qh::field-name = 'xyz'

Don't get mad at me, but your piece of code seems to be an academic piece of work and does not make sense to me. And please use code tags when you post code the next time it makes the code much better readable for us.




Heavy Regards, RealHeavyDude.
 
Hi Dude, hope you are doing well. :)

Actually i am facing the same problem with procedure editor. In my personal laptop when i write code in procedure editor then it will display in simple text format. My apologies for this, next time i will make sure to write proper code tags.

Requirement:- I want to take customer number from user and depending on that customer number i will search that if customer have orders associated? if yes then i want to create dynamic temp-table with customer name and all its orders and if no then other table with status. the code i am trying for this:

Code: 
DEF  VAR  qh       AS   HANDLE       NO-UNDO.
DEF  VAR  i-chk  AS    INTEGER     NO-UNDO.

CREATE TEMP-TABLE qh.

SET i-chk.
FIND customer WHERE CUSTOMER.custnum = i-chk.
IF AVAILABLE CUSTOMER
THEN DO:
     IF CAN-FIND(order OF customer)
     THEN DO:
        qh:ADD-NEW-FIELD('c-name','char').
        qh:ADD-NEW-FIELD('c-ord-num','int').
        /*populate temp-table fields with order table values*/
     END.
  ELSE
     qh:ADD-NEW-FIELD('available','log').
END.

  qh:TEMP-TABLE-PREPARE('prac').

Heavy Regards, Rajat.
 
Last edited by a moderator:
I just tried your code and it compiled fine, I don't know what you mean by not finding the 'prac' reference.

This is how you'd assign a field, this also works for me:

qh:buffer-field("c-name"):buffer-value = "xxx".
 
For that you don't need a dynamic temp-table. You can do that with a static temp-table too. I prefer a static temp-table over a dynamic one when a static temp-table is okay for the job. By the way, I don't see any code in your example where you destroy the dynamic temp-table in order to avoid a memory leak. You need to take care of every handle based dynamic object that you create: You create it, you destroy it. There is no such thing as a garbage collector like there is for "real" objects that were introduced with OOABL to the language some time ago.

Your code right now adds different fields to the same dynamic temp-table depending whether a record in the customer table is available or not. While you can do that it means that you need to inspect the schema of the temp-table before another logic can use it because it won't know the schema. Why don't you add all necessary fields to the temp-table and just populate it conditionally.

Another thing that I noticed: You can't use the buffer-field method on the dynamic temp-table - this method is only valid for buffer objects. You can either create a dynamic buffer for the dynamic temp-table or use the default buffer that comes with it.

Code: 
define variable bufferHandle as handle no-undo.
 assign bufferHandle = qh:default-buffer-handle.

Heavy Regards, RealHeavyDude.
 
Hello Everyone, hope you all are well.

As of Now, I could understand how to use dynamic temp-table but I am unable to understand: Why to manage pointers, dynamic buffers, methods, properties of dynamic objects and lot more stuff like we have to take responsibility of deleting them as well. If we can do that by using static temp-table then why to take dynamic temp tables.

Perhaps, this is because of the following reasons:
1. Efficiency or something due to run time memory allocation.
2. We cant get all method and properties with static objects.
3. We have specific scenarios where we have to use dynamic temp-table, if yes, then please share what are they?

Please Suggest.

Thanks & Regards!
Rajat.
 
You asked this exact same question last week and at least two of us answered it. But I'll try again.

1. We have a generic 'log the contents of any table' procedure. So you can run it like 'RUN log_table(foo)', where 'foo' is a handle to a buffer or dynamic table, and 'log_table' dynamically figures out all the field names and their content. To do this statically, you'd have to have a separate procedure for every table, and add a new procedure every time you created a new table.

2. We and others have a generic 'turn any table into an Excel spreadsheet' procedure. Exact same idea as above, but a lot more complicated.

In a nutshell, static references are arguably simpler and arguably more appropriate when the logic that operates on the reference is tightly bound to the specifics of the table (eg. business logic). Dynamic references are much more flexible and arguably more appropriate when the logic is generic regardless of the fields in the table.

I think there is some difference of opinion here on PT, but where I work the default is static and we generally use dynamic on an 'only if you need it' basis. That said we use it a LOT and there are situations where if we didn't have dynamic the alternatives would be truly awful.
 
Thanks for replying Greg!

Sorry to say, but Last time I faced difficulties in creating dynamic temp-table and asked question regarding the same. Now I could make that for any of database table but curious to know its advantages.

What I understand from first point is, when we pass handle (foo) to internal procedure then foo(pointer) is already connected with any buffer,For ex:

Code: 
DEF VAR bh1  AS HANDLE NO-UNDO.
DEF VAR bh2  AS HANDLE NO-UNDO.

CREATE TEMP-TABLE bh1.

bh2 = BUFFER CUSTOMER:HANDLE.
bh1:CREATE-LIKE(bh2). /*POINTER CONNECTED TO BUFFER CUSTOMER*/
RUN LOG_TABLE(bh1).


Perhaps, I assumed it wrong, so could you please share code related to your first point above, that would be helpful.

Thanks & Regards!
Rajat.
 
I honestly think you would benefit from some formal training, either from Progress, or from a consultant. At the very least, get to one of the PUG challenges. A lot of the questions you ask are very fundamental questions.
 
I'm not exactly sure what you are asking. But I'll give it a shot:

1. I would imagine that LOG_TABLE is a generic procedure that will take any table with any arbitrary combination of data types in it and write its contents out to some log file. LOG_TABLE would not have any hard-coded, aka. static references to any tables.

2. For this to be useful, the procedure you wrote above would, in our world, typically look more like this. Sorry for my inability to find the code tag thingie in the PT forum ;)

/* create_customer.p */
CREATE customer.
customer.num = 1
customer.name = "RAJAT".
customer.wearing_tie = TRUE.
customer.birth_date = 11/12/1965.
customer.hobby[1] = "macrame".
customer.hobby[2] = "skydiving".
RUN LOG_TABLE(TEMP-TABLE customer:HANDLE).

The point is, create_customer.p knows all about what a customer is, it has hard-coded (static) references to all its fields, and everything about it is tightly bound to the customer table. As such the code is arguably easier to read and write, and it benefits from compile-time type checking, which means it is less vulnerable to run-time errors.

But LOG_TABLE is the opposite. It is arguably harder to read and write, and it is much more vulnerable to run-time type errors. On the plus side, it can be run unchanged from create_customer, create_invoice, create_vendor, etc. and it will log the table content in the same way regardless of who calls it.

Disclaimer: some people on this forum (who totally know what they are talking about) may argue that dynamic references are appropriate 100% of the time, and others would argue the exact opposite. It depends on your situation and skill level, I suppose. We are definitely in the camp of using both.
 
You must log in or register to reply here.
Back
Top