Yes, it’s possible to use bb for this. I’ll reply with more details later today.

So, do you need to connect to mssql from bb?

Or is that only "after extracting data from mssql"?

You can connect to mssql with a sql pod: https://github.com/babashka/babashka-sql-pods#ms-sql-server-support You can download the pod separately and load it with (babashka.pods/load-pod "<path-to-pod>") and then execute the above code. Another way involves maybe shelling out to https://learn.microsoft.com/en-us/sql/tools/mssql-cli?view=sql-server-ver16 or so. For csv you can use clojure.data.csv which is built into bb.

Your guidance is enough for me to do the task. Thank you so much for your kind guidance. 🙂

This should work the same way, you're just shelling out to clojure. But it could be that you're having some :deps in bb.edn itself which are downloaded?

the bb.edn file in question is here: https://github.com/Ramblurr/probematic/blob/main/bb.edn

Yes, this:

:deps {local/deps {:local/root "."}}

Btw, don't use the name local/deps: use a unique name there since if you use the name local/deps in other places, you'll get caching problems

hmm ok don't remember how that ended up there in the first place, probably copied it from another project. removing it seems to solve the problem. thanks!

Ah, I didn't know about this either. The local/deps solution was originally in the docs but it looks like this was changed a few months ago: https://github.com/babashka/book/commit/b88e3646bb726ed16f2799986f4603719784bee3 bbin is actually generating scripts that use local/deps at the moment so that sounds like a bug we'll want to fix

@U0CLCL6T0 yeah, please fix :)

Feel free to ping us here if you have any questions (we love asdf!)

It's almost embarrassing how the "main" babashka-plugin has been broken since M1 came out, should have been replaced with your fork much sooner. FWIW, I highly recommend checking out https://github.com/jdxcode/rtx. Without evangelising too much, it's better in almost every regard, piggybacking on the asdf plugin repo, and respects .tool-version files for converts.

Right, we're also investigating rtx as an alternative. ASDF works very well, but it has one flaw – it adds up to 400ms to every invocation of java, clojure, bb etc. This can add up. A couple of possible fixes for this: • Switch to rtx • Build a PATH https://github.com/asdf-vm/asdf/issues/290 • Use https://github.com/asdf-community/asdf-direnv

I feel like betting on rtx is a little risky now (as asdf has a bigger community), but I agree that rtx has the better design

(Another problem with asdf's shims, other than performance, is that they are on the PATH even if you don't have a .tools-version. It wants to own the world. AFAIK rtx with its PATH-modifying approach doesn't have that problem)

Speaking of things that are worse than Nix () I need to get around to opening a PR for my Nix derivation that pulls the pre-built binary version of Babashka, and then convince the powers that be at Pitch (whoever they might be) to maintain that. 😜

Doesn’t ring a bell. Need more info, repro

Ah, maybe it's not a problem with bb. Something to do with cider-nrepl. My minimal setup with deps.edn project and I'm seeing the same thing:

Error printing return value (ClassCastException) at clojure.lang.Numbers/lt (Numbers.java:253).
class clojure.lang.PersistentVector cannot be cast to class java.lang.Number (clojure.lang.PersistentVector is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')
ERROR: Unhandled REPL handler exception processing message {:op analyze-last-stacktrace, :nrepl.middleware.print/stream? 1, :nrepl.middleware.print/print cider.nrepl.pprint/pprint, :nrepl.middleware.print/quota 1048576, :nrepl.middleware.print/buffer-size 4096, :nrepl.middleware.print/options {:right-margin 70, :length []}, :session f7cb9ce8-09b8-4c25-8d2f-b8fadd762169, :id 14}
java.lang.ClassCastException: class clojure.lang.PersistentVector cannot be cast to class java.lang.Number (clojure.lang.PersistentVector is in unnamed module of loader 'app'; java.lang.Number is in module java.base of loader 'bootstrap')

:length []?

yeah, it seems CIDER not sending the right thing, not sure how that broke in my setup.

Maybe it's in your elisp somewhere? not sure, but good to know it's not a bb problem

Yup, turns out I messed up my cider-print-options and didn't notice. It coincided with the time when I started debugging a bb script. Apologies for the noise.