We don't use the space after column 80 on purpose, but when you are typing a SQL statement from memory you can forget to stop typing in a logical position, so wrapping the code after column 80 on an exec sql line reformat would be a useful addition.
The addition of being able to insert a newline without triggering the formatter would be very useful too (thanks "x y" for the idea) as I find it frustrating when the RPG lines after my sql statement get dragged into my sql statement by the formatter if I haven't entered the semi-colon on the sql line yet (it did once cause a serious problem when a free-form eval statement was dragged into a sql WHERE statement and the programmer didn't notice!) Having the sql formatter not trigger after a paste would be useful for the same reason.
We'd like to use /* */ comments "inline" and // comments before/after the exec sql statement, if you can fit some options like that in. I've never thought of using the space after column 80 for comments on sql lines... I don't even use it for comments in RPG. (SEU users who don't set their terminal program to use 132 width screens don't think to look for comments over there more often than not.)
Any chance we can get the usages of files and fields from a sql statement into the outline? (with or without an F-spec.) This sounds like a job the auto-formatter might be able to help with.
-Paul.
-----Original Message-----
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Taryn Morris
Sent: 11 June 2014 19:10
To: wdsci-l@xxxxxxxxxxxx
Subject: [WDSCI-L] Feedback regarding the automatic SQL Formatter
The development team is looking to improve some functionality with the SQL automatic formatter and we are seeking your feedback to give us some guidance. Some of you may have experienced the frustration of pushing embedded SQL code beyond column 80 while the automatic formatting preference is turned on. Once the cursor is moved to another line, the formatter will re-format the SQL statement but leave behind any code pushed beyond column 80, since anything after this is generally considered a comment and should be ignored.
We are proposing a solution to have another preference to turn on with the SQL formatter that will allow SQL that goes beyond column 80 to be considered part of the statement and not a comment. This will prevent the formatter from ignoring any code that may get pushed out during a reformat of the statement.
What we would like to know is how many of you use the space beyond column
80 to write the comments for SQL statements, versus including it directly in the code (ie: using '//' or '/*' to comment). Also, would this solution help those who use automatic SQL formatting? If this solution helps, we would appreciate any recommendations on what the new preference should be named in order to make its intention obvious to the user.
Regards,
Taryn Morris
Software Developer for Rational Developer for i
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
Scanned by MailDefender - managed email security from intY - www.maildefender.net
Important, this email transmission and any files with it are strictly confidential to the intended recipient and may be legally privileged. Any views or opinions presented are solely those of the author and do not necessarily represent those of BHSF. If you are not the intended recipient, you must not copy, disclose or distribute its contents in any way. If you have received this e-mail in error, please notify the sender and delete the e-mail from your system.
We have taken steps to ensure this email and attachments are free from any virus but do not accept any responsibility once this e-mail has been transmitted. You should scan any attachments for viruses. No contract may be concluded on behalf of BHSF Limited by e-mail.
Registered Office: BHSF Limited, Gamgee House, 2 Darnley Road, Birmingham, B16 8TE. www.bhsf.co.uk Registered in England number 35500. BHSF Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority.
midrange.com
