Re: SQL is amazing was ( Avoid Level checks )

I considered using a file to record the SQL.

Two reasons I did not.

.  On recreate a file I wanted an easy way to recreate the indexes. By having a program for each PF/table the procedure was simple and obvious.

.  Using our source control system I had an easy way to ensure the scripts could only be altered in a controlled manner. Plus you need to keep the SOX auditors happy.

Hmmm dont hear so much these days about SOX.  Do you guys still do these audits?  Anyhow you need to follow best practice, I remember my days as a cowboy, not good.

SQL is powerful enough that I never needed to consider extending its ability.

Custom anything just adds complexity to the system, and things are complex enough. I always tried to simplify. In fact I had a guideline, 'If things are getting complicated then my approach must be incorrect'.

Frank


On 01/07/2022 4:32 am, Mike Jones wrote:

Or, even better, put those SQL scripts in a real DB2 table instead of using
separate text files or source members. That way, you can easily run SQL
queries to find your desired scripts (ex: search for a specific table or
column name), or even easily run SQL UPDATE statements to change the
scripts in bulk.

Run them using a central custom SQL script processor, which
allows centralized error handling, error logging, and performance logging.
It also facilitates the ability to extend SQL's capabilities to things like
conditional execution of SQL statements within a script.

Mike

On Wed, Jun 29, 2022 at 2:46 AM Brian Parkins<goodprophet.bp@xxxxxxxxx>
wrote:

Frank, interesting that you used embedded SQL.

Was there a reason that SQL scripts (text files) were not acceptable?
(These could then be used through an number of SQL processors such as
RUNSQLSTM or the ACS Run SQL Scripts interface.) Even a CL program
containing RUNSQL statements seems less involved than writing SQLRPGLE
programs for "housekeeping".

Just curious. (Applaud the approach!)

Brian.