-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
For complex SQL queries, use separate *.sql file instead of dbMemo SQL variable in *.bas #336
Comments
@grv87, have you checked Wiki Options Build Options See "Force import of original SQL for queries". It does exactly what you are asking. As to parsing and formatting the Using the SQL import force option will import the query, and then set the SQL to the SQL file; there isn't really a great way to do it without building a whole new sanitize and parse and build routine (which I'm working on...slowly). |
@hecon5, thanks. I understand the difficulty of editing
|
Ok, to start off, the issue isn't that this tool can't, it's that to do this requires:
All that may take considerable processing time and resources for a tool that is designed to be light and fast, and does 99% of what you're looking for now. So, it may not be ideal, but given Can you help me understand the following statements?
These two statements seem (to me?) to be at odds with each other. Either you're looking to export the SQL and edit the SQL directly (and force import of the SQL) or you want to edit in the While we do some fancy Sanitizing in the Lastly, are you editing the Query in the query editor, or are you editing in a text file and then importing? For the vast majority of cases, it's much better to edit in Access itself, export, and then build from the exported code, and not directly edit the In closing, I'm trying to build a file parser for a separate setting (Connection link), but as I said above, it's not straightforward and the risks are high, the rewards are low, and so the progress is very slow. |
These statements don't contradict. I'd like to use a file format best appropriate for each kind of code.
So, 'Force Import of SQL' doesn't do what I ask. What I ask is a middle between this option turned on and turned off.
Right now, I edit simple queries in Design mode. One of my projects have two instances (DBs with identical structure but different data). I used to copy queries from one to another and backwards, but at some point they anyway diverged. In order to fix this drift, I'd like to export all their code to files, manually compare and merge them (with text editor) and import back. @hecon5, do you see any technical difficulties with proposed temporary solution? It doesn't require a parser. |
That's a parser by definition, as far as I can tell... If that line isn't in the I think the best way to deal with this is to either live with it, or we could build a parser (which, admittedly would have other benefits as we could parse out connections and the like). See links above for related issues, but if this is something you're really after, I think a parser is going to be the way to go. |
A user who uses this feature obviously should not delete SQL file.
You don't need a parser to compare that one string starts with another. Never mind. If it'll become a serious issue to me, I'll make a PR with what I propose. |
@grv87 - I do like the idea of extracting out the embedded SQL from
Splitting out the embedded SQL statement would also have a second benefit. As a future enhancement, I would also like to format the SQL file content with some basic line breaks and indenting so that every query is exported in a consistent and easily readable format. This will make diffing SQL changes in queries a breeze in the native VCS tools, instead of having to format and compare the SQL manually. I made some headway on this project a couple years ago, but never finished it. (If anyone is interested in working on this, I was adapting https://github.com/zeroturnaround/sql-formatter to a single VBA class for use in this add-in and potentially other projects.) I can see how managing the SQL in the |
To make sure @grv87 and @joyfullservice are clear...I like the idea of moving SQL out of the My chief concern is changing this is a breaking change (once you convert this way, going in reverse on your code base is not going to be possible), and users should be aware it's about to happen. I also think we should have some robust build error detection to ensure we don't forget to put the SQL back in (and so users are aware of what just happened so they can fix it). If we do this (which, I think is a good idea, clearly that's not been conveyed, and that's on me), we should start out with this being an option, and off by default. We should advertise this, but I don't think we should strip out the Secondly, the more I think of it...I think we should build at least a rudimentary parser. Being able to sanitize the connection string and the SQL would be heaven, and would allow me to get rid of the last vestiges of PII / server secrets in the Queries from my code base. Being able to remove the If we did this, we could potentially save the I'm almost wondering if we could have one Then, prior to rebuilding, you could go through the |
Complex queries have *.bas file starting with
dbMemo "SQL"
line. SQL code in this line can't be easily formatted, diffed or edited. It hinders the purpose of version control.I can also export, reformat and edit
*.sql
file. But this file won't be used in building from source unless I copy it back to *.bas. Also, storing the second copy of SQL query would violate DRY.I propose that for complex queries (with
dbMemo "SQL"…
) the tool:' dbMemo "SQL" = see in this_query.sql file
And vice versa on building from source, of course.
The text was updated successfully, but these errors were encountered: