In the ABL2DB work I have just encountered my first .df with UPDATE TABLE|INDEX ... BUFFER-POOL "Alternate". This was a bit of a surprise since I was used to only ADD and DROP statements. Easy enough to handle (aka ignore, for now), but I am wondering if there are any other UPDATE TABLE|INDEX variations which I don't know about.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Quite a few actually... a lot of fields on the _File table can be updated (labels, descriptions, buffer pools, etc).
For indexes I "think" only the name and if it is the primary index can be changed through an UPDATE in the DF. Possibly a few more.
I'd expect all the table attributes you see in the Data Schema tool - Names, descriptions, etc.
if you change them, then you'll get an "UPDATE TABLE|INDEX" in the .df.
OK, I probably should have been more clear. This tool is not intended to be used on an incremental.df. So, DROP, for example, is a reason to just quit right on the spot because it means that this assumption is violated. I would be inclined to think the same of UPDATE, except that in the Alternate buffer-pool case, it is in the base .df. I guess this means that I need to check whether it is a BUFFER-POOL statement or something else. Is there anything else that could be in a non-incremental .df?
For a non incremental DF the only thing I can think of that will generate an UPDATE would be the buffer pool. Everything else I can think of is included with the ADD (as it should be).
OK, I'm going to work on that assumption. My first reaction was, what the heck is an UPDATE doing in an original .df?
Less coding for PSC, because all ABP assignments are done as alterations to an existing table/index?
I don't see why ABP assignment couldn't have been part of the ADD TABLE or ADD INDEX statements. But for whatever reason, it's an UPDATE.
I'm with you Rob. Seems like it should have been a part of the ADD TABLE or ADD INDEX