Hi. Looked through reams of text.rewrite but I haven't been able to take away something to help me out, so here it goes.

I have a custom text table tdsls900 that I can call from Quotations.

This contains txtx.e text and indexed back to tdsls100.

I text.to.buf my tdsls900.txtx.e field, manipulate the string to add some tags, and THEN I want to write the values into tdsls100.txta.

I selected text.write, tried my best to make sense of code to write values, commit.transaction() yet I don't see the text being written back or an error.

I left lots of the text.rewrite blank to select defualts maybe this is whee I am going wrong.

I am not however writing text from a file on a server which I read a lot of. I am taking a txtx field, manipulating it into a string array, then want to update it back to a txta field ...


________________________________________________


select tdsls100.* from tdsls100
where tdsls100.qono =:tdsls900.qono
selectdo
endselect

select tdsls900.*
from tdsls900 where tdsls900.qono =:tdsls100.qono

selectdo

text.to.buf("tdsls900.txtx.e","2",8,packaging)

packaging(1,1)="PT:"&packaging(1,1)
packaging(1,2)="PT:"&packaging(1,2)
packaging(1,3)="PT:"&packaging(1,3)
packaging(1,4)="PT:"&packaging(1,4)
packaging(1,5)="PT:"&packaging(1,5)
packaging(1,6)="PT:"&packaging(1,6)
packaging(1,7)="PT:"&packaging(1,7)
packaging(1,8)="PT:"&packaging(1,8)


endselect


select tdsls100.*
from tdsls100 FOR UPDATE
where tdsls100.qono =:tdsls900.qono

selectdo

text.rewrite("tdsls100.txta","","","","","","","","packaging")
db.update(ttdsls100, db.retry)
endselect


commit.transaction()


Am I on the right track here ? As stated i get no errors but also get no update neither !

Depends on where this is called. Did you place this in tdsls100ue? If so, is the update called in one of the 'before' hooks for update and/or insert?

If in a 'ue' and in one of the 'before' hooks, you don't have to read the field (it is already there before the record update) and you don't need the commit (it is done from standard DAL processing). Also, the 'ue' script is only executed when something in the record is modified and when it is inserted. Since a record isn't updated when text for tdsls100 is changed, the user exit isn't executed.

You are also missing an important step in the text process. 'text.to.buf' loads text into a string array from the text table. 'text.write' takes the contents of a data file (text) and loads it into the text table. Once you have loaded the buffer and (optionally) modified it, you have to write the array to a file (can use a loop with seq.puts - can be a temporary file in BSE_TMP) then load that file into the text.

text.rewite("extern.variable or table.field", language$, kw1, kw2, kw3, kw4, troup, editopt, "name.of.temp.file.with.text.txt")

strings for 'kw's, tgroup, editopt are optional. Keywords are good to use for easy lookup of existing texts.

Hi, it is called in the ue.after.after.save.object

Here is some history on why i am doing this.

In old IV, we had customized the standards BaanIVtable to add more text fields and had to get sourced modified to send it across to a Sales order. This time in LN we want to take a number of text fields, concatenate them, tag them and write them back to an LN header text field so that they get transferred across without source changes.

I edit the custom table sls900, and upon saving the ue does trigger, reads in my text I just entered, changes the text to 'tag' a prefix on each line, then that is where I am having the problem ....

I was worried that LN would not allow me to just 'skip the write to a file' then do an update but i was not sure at this point ...

Is this the only way to do this ? Write to a file, then update it ? I also don't think I need a ue on sls100 but you never know ... :) ...

When you mentioned user exit script I assumed that you were triggering from a standard table. I have only used UE scripts for standard tables - for custom tables I use a DAL2 script connected to the table so I can use more event hooks. If triggering from custom tdsls900, why not create a DAL to manage your text?

I don't know of a better way to update text from buffer than using the intermediate text file. I see that there is a "text.buf.to.field" function in LN, but I haven't had a chance to try it yet. You can also load text directly to file and modify/append to it there (text.read), but I find that the array handling is a bit easier to do unless just concatenating texts.

I think the reason that I had to abandon DALs ( besides the fact I don't fully understand them yet ) is the relation ship between the Quotation and Sales Order sessions and my custom table ...

I envisioned the following in my head:

1. Maintain Quotations. If no text entry match in my custom table, then add one.

2. Maintain Sales Orders. If no text entry match in my custom table, then add one.

I dont think I can use a DAL for either of these sessions because LN already has DALs. Is this a fair stmt ?

3. Once I do decide to maintain the text in my custom session / table, then initiate a ue DLL to format and concatenate all my and write back my text changes to the sls100.txta or sls400.txta or BOTH table.

I am just starting to learn about these things as I never had them in IV and hoping to make some progress to the end goal of adding text without modifying source ....

I dont think I can use a DAL for either of these sessions because LN already has DALs. Is this a fair stmt ?

Sometimes. If you are careful you can update other tables using SQL (select & db.update without commit) instead of DAL in other table's DAL scripts. This works well for reference and text fields where there probably isn't standard logic around the fields. If there is any question about a field (expecially codes & quantites), I will call DAL to update it to ensure that proper business logic is executed. I have manipulated reference fields and texts in other tables in both DAL and UE scripts without incident. Remember that a UE script is a small portion of a DAL, so any logic you would put in a UE could be added to a DAL of a custom table, using select/db.update or DAL to update the other table(s). There is nothing wrong with using DAL to update other tables in a DAL script, you just have to watch out for circular references. When updating from a custom table DAL, you probably won't run into this case unless you have a UE script for the standard table that is updating your custom table via DAL.

How is the user exit script named? That was already asked here, and is important! tdsls100ue or tdsls900ue?

if tdsls100ue:

DON'T select tdsls100 again, it's already selected. You will certainly mess up with the standard logic this way. DON'T do a commit.transaction() in a user exit script (and also not in a DAL). NEVER EVER. It will certainly mess up with the standard logic and create corrupt data. The transaction is controlled by an outer control structure (4GL engine or entry points in processing DLLs).

DON'T use a separate table (tdsls900) as a "backpack". Add your new text field to tdsls100, this will cause less(!) trouble during software upgrades.

It was off tdsls900ue my custom table ... Yeah, I had commented those calls out but was trying a bunch of things in test env't to see what would happen.

DON'T use a separate table (tdsls900) as a "backpack". Add your new text field to tdsls100, this will cause less(!) trouble during software upgrades.

Interesting comment Ulrich. I had also planned to originally just add the fields and do away with lots of this trouble. We are under the impression that upgrading to future feature packs may result in issues if NEW table defs come out. Is this an easy thing to update without losing data etc ?

One thing I was trying to do is write the text back to quote and sales tables which in the end I really don't need to do. If I update my table ( if I keep it ) I would update the table with the Sales Order, Quotation number or both and do select stmts to that number to pull my data but I will investigate further. Thanks for the input everyone !

When you're installing solutions or new feature packs that change the definition of a modified table, of course you will have to redo your modification (consolidate it with the new definition form Infor). However, it is very easy to check the fields for a particular table in your test environment and rebuild your customized one accordingly. This usually takes less then a couple of minutes per table. However, when using backpack tables, this tends to sneak into a lot of application code. Most of the time standard sources (eg DALs, Session scrips) will be modified to somehow interact with your new table, displaying descriptions, adding records there etc. That code needs to be updated with every solution/feature pack too, and usually it's more work. Also, table defintions are changed by Infor not very often any longer with simple solutions, most of the time only with feature packes. And then you have to look over all your addons anyway, since a lot of functionality may have changed under the hood.

In short: New Table fields are *very cheap* in terms of maintainability. Modified standard sources are more expensive (but even not so expensive as most people think, when done and commented(!) properly). What costs a lot of time and money during updates (and is nontheless done by every customer) is the modification of standard *reports*. Customizations there are particularily hard to consolidate with changes in the standard report, since they usually involve a lot of structural changes that cannot be documented in an easy-to-read way.

Thanks. That helps us understand possible implications of trying to backpack our data.

We will work towards adding our fields to existing tables as opposed to the original thought process.

That will certainly make most of what I was asking about here obsolete as i don't need to make a lot of these record entries and updates.

Thanks everyone for their comments and suggestions, it certainly helped out a lot .....

I happen to have come across these posts here and I can't resist to express my disagreement with Ulrich in this case... My advice - from a upgrade-ability - will always be: AVOID changing any standard tables, even more than scripts and others! I also disagree with your suggestion that new extension tables require coding and adding to existing tables don't. They require as much coding, however if you just do it in a new separate extension table, you can avoid having to change STANDARD code, and just write UE scripts or DALs in the worst case, ON THE NEW STAND ALONE table, rather than on standard objects.

I will be happy to hear your thoughts.

Cheers,
Eli Nager