Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
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