Search results

Your trigger file: { deletetrigger.i customer } the include file // deletetrigger.i procedure trigger for delete of {1}: run scankey ( ( buffer {1}:handle ) ). Or if you have a strong dislike for ordered parameters: { deletetrigger.i &table = customer } with // deletetrigger.i...

You will need to transform the static buffer to a buffer handle. Static means at compile time. So you will need a stub program per table that contains the table name, you already have this for your delete trigger procedure. Maybe the following helps: // this is the delete trigger, it contains...

You already have the full record in your static buffer. By accessing the handle to this static buffer you can access the buffer dynamically. You do not need the rowid.

You seem to be mixing dynamic and static up incorrectly. The rowid function only works on a static buffer - rowid( somebuffer ) - somebuffer must be a static buffer. The rowid attribute is an attribute on a buffer handle. The buffer can be dynamic: create buffer hb for table 'sometable' or...

You can only access the static buffer dynamically if you can use the static buffer name. trigger procedure for delete of abc. def var hb as handle no-undo. hb = buffer abc:handle. message hb::buffer-field(1):buffer-value. Since your delete triggers need to be static anyway due to the...

Ah, so you are still inside your delete trigger and trying to get dynamic access to the buffer used by the delete trigger? I do not think that that will work. While you can create a dynamic buffer for the table, you do not have access to the static buffer used by the delete trigger.

I was answering: A dynamic buffer has a rowid attribute, you can find a record using the find-by-rowid method. But your question makes no sense. Maybe show some (psuedo) code illustrating what you are trying to do.

Extract the source code from the prodict.pl and debug it.

So program-name(1) is usable, you just need to ensure that (part of) the name of your trigger procedure matches the name of the table it is for. Our delete triggers are all named <module>/td/td<table>.p - so can easily get the name of the table the trigger is for.

The write trigger supports naming the old and new buffers, so you could keep these the same. Alternatively / for other triggers you may be able to use the program-name function.

How are you planning on doing this (without an include), since the trigger procedure must start with a static: trigger procedure for <event> of <table>. We use a (generated) single line .p with the table name passed as a preprocessor to an include that does the actual work.

Have a class based example as a starting point: https://abldojo.services.progress.com/?shareId=62838cdf3fb02369b254634f def var odelete as delete no-undo. def var lcjson as longchar no-undo. odelete = new delete( 'order' ). odelete:populate(). lcjson = odelete:write(). message string(...

I cannot make heads nor tails of your code. // first you need to prepare your temp-table based on the index create ht. for each _file... ht:add-like-field. end. ht:temp-table-prepare(). // then you get records and populate temp-table create hq. hq:query-prepare(). do while hq:get-next...

after pressing share, a url is copied to your clipboard - you need to provide the url.

Maybe share your "working" code on ProgressAblDojo

So you need to not do that and only create what you need when you need it. If you want a temp-table with multiple records, you need to create the temp-table once and then create multiple records in that temp-table.

You are creating the dynamic buffer, query and temp-table per index field of the unique index on table 'test'. So you are: not getting what you need leaking memory since you are repeatedly creating dynamic objects over each other

Since JSON is not a line based format, you cannot simply append like with the output statement, so you need to: read-json file into temp-table create temp-table records write-json temp-table to file

You may also want to have a look at the quoter function: Progress Documentation

-tok is a client startup parameter, so it needs to be on the command line directly or indirectly (-pf) of whatever is starting your ABL session.