Search results

Those are all possible approaches, you can also use the outcome of this as a default that the user can change if needed. Upon reading data, if you get an exceptionally high number of errors due to data type mismatches, you could retry.

What ideas do you have so far?

You can compare them, you just cannot use them in a query. So I think you are going to need to rethink what you are trying to achieve.

Both a longchar and a clob are large objects, so this is not going to work.

Why could you not write:

Deserialize your json to a temp-table and use that, this should get you started: def var lcjson as longchar no-undo. lcjson = '~{"Customer": [ ~{ "cust-num": 121, "name": "Jack", "state": "Texas", "city": "Houston" } ]}'. def var ht as handle no-undo. def var hb as handle...

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.