Search results

Yes, although with your structure you will need to disect the json yourself using JsonObject and JsonArray.

That's not really your calculator though, is it James ;-). My calculator returns an error:

Working as documented Progress Documentation

If you just need to know which tables are hit, to get insight into the black box your application may be, you can monitor this using _TableStat or _UserTableStat To not reinvent the wheel, you could look at - the free version of - ProTop.

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.