Command-line capability

Kudos for SQLPro being the first OSX client that I've found that works out-of-the-box with no configuration hassles for SQL Server.

Would it be possible to add the ability to run the app as a terminal application, so that I could integrate it into other flows (build automation, invoking via emacs or other editors like VS Code) - essentially any tool that plays well with stdin/stdout applications?  Just the ability to run queries would be sufficient - there's no need to abstract the schema browsing capabilities across different vendors.

2replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I like the idea and I’ll think about how to implement it. It would unfortunately be awhile (no eta) as to when I could implement it.

  • Thanks.

    Without knowing much about your codebase, I can't offer much in the way of suggestions, although given the rather large number of app-specific dylibs in your Frameworks directory of the bundle, I'm assuming you have a rather nice class model for abstracting away the grizzly details of vendor-specific apis.

    Other than decoupling the data connectivity from the UI interface (if you made the presence of a UI window or pane a precondition of a db connection), I can imagine that the biggest hurdle would be coming up with a decent set of command-line options that could specify all the necessary parameters needed for each of the different vendor backends.  You could obviously go the way of ODBC and created a dreaded "connect string" that is just a bunch of params mashed together into a single command line option, but you could also just require that the user set up a Connection first in the UI, and then the command line could be just an option to indicate the name of the Connection, as well as an optional password (or rely on a prompt).  This ends up, unsurprisingly, being rather like the venerable ODBC "Data Source" feature.

    As far as my own requirements go, a basic delimited column/row format would be sufficient for automation.  A crude sqlite3-like column formatting scheme -- widths determined by the sizes of the first row of output, or positional size specifiers provided by the use -- would be adequate for other tool automation.   If you wanted to be fancy/slower, process the entire result set first to find the widest entry for each column; I know sqlite doesn't allow for the specifying (or honoring of) length attributes for columns, so a truly cross-vendor implementation of knowing the format of the output before you read the results would not be possible.

Like Follow
  • 1 yr agoLast active
  • 2Replies
  • 595Views
  • 2 Following