@akiva: some-> instead of -> at least stops if it hits nil - which isn't error checking per-se but sometimes it is all you need

That’s a good short circuit, you bet.

hoopes: also, instead of checking explicitly for errors, we typically have exceptions and exception handlers when runtime errors are an issue

so the whole let block can be in a try/catch and then you could potentially throw at each step if there is a problem

hoopes: in practice having to opt-out of short circuiting on errors (via try) leads to better reliability than having to opt-in to checking for errors

@noisesmith: thanks - i'll see what i can work up with that strategy

Hey, new to clojure and the whole thing, probably a stupid question but I want to require a package only for the repl to try it out, how can I achieve that?

People often recommend lein try for that sort of thing

@donaldball: yeah, I am using lein but I can’t figure out the command with lein to do it even...

@donaldball: yeah, just found out for that

https://github.com/rkneufeld/lein-try

oooh, now I get what you meant. I didn’t understand you mentioned a plugin called “lein try”, thought you meant that "people use lein for that, try it"

Heh, sorry for the ambiguity, should’ve linked

haha, don’t worry, thanks for trying to help @donaldball! Sorry for not understanding you correctly

Has anyone dealt with this error? SQLException No suitable driver found for jdbc:sqlserver:

And if you have can you please help me get around it? I have been fighting it for a day and I can't afford more time but it is stopping my progress.

I have added the jar to my classpath and when I try (. System getProperty "java.library.path") C:\\Program Files\\Java\\JDBC\\sqljdbc_4.1\\enu\\sqljdbc4.jar; is part of the path

So now I am completely lost

Perhaps the class isn’t loaded

Looks like com.microsoft.sqlserver.jdbc.SQLServerDriver

When you type that at the repl, does it return the class?

CompilerException java.lang.ClassNotFoundException: com.microsoft.sqlserver.jdbc.SQLServerDriver

So how do I load the class?

In java, you’d do Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver”);

tbqh I think clojure does that automatically when it tries to resolve a class, but you could try (Class/forName “com.microsoft…”)

Are you sure the path to that jar is correct?

Yea it is followed to the jar

I’m afraid I’m not of much help then 😞

Are you using leiningen by chance?

yes I am

Though curses, that’s not much help because maven doesn’t have an artifact for sqljdbc

sigh

If you don’t require the microsoft driver, you could try jtds

Leiningen value would be e.g. [net.sourceforge.jtds/jtds "1.3.1"]

Jdbc URL format is http://jtds.sourceforge.net/faq.html#urlFormat

That might at least let you make some progress until you can sort out your classpath issue with the Microsoft driver

Clojure.java.jdbc has some instructions for installing the Microsoft driver in your local maven repository: https://github.com/clojure/java.jdbc#releases-and-dependency-information

Re: MS SQL Server driver — it’s free to download and you can install it into your local Maven repo cache with lein-localrepo.

That’s how I test clojure.java.jdbc against SQL Server. I have the Microsoft driver installed locally (on my Mac) and then just depend on it in project.clj like all the other drivers I test against.

You can d/l the MS JDBC driver here: https://www.microsoft.com/en-us/download/details.aspx?id=11774&displaylang=en

Here’s lein-localrepo: https://github.com/kumarshantanu/lein-localrepo

@jcomplex: ☝️

@seancorfield: @donaldball thanks for all your help

Hopefully you are now unstuck?

@donaldball: I am now dealing with this: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006f577797, pid=12708, tid=20412 # # JRE version: Java(TM) SE Runtime Environment (8.0_66-b18) (build 1.8.0_66-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.66-b18 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x67797] # # Failed to write core dump. Minidumps are not enabled by default on client vers ions of Windows

...

That is not good. Core dump tends to indicate a JVM bug or something wrong in native code.

Do you know what’s triggering it?

I’d immediately be suspicious of the sqlserver driver, but @seancorfield has pretty good test in clojure.java.jdbc iirc

Folk on this thread suggest the jdbc uri format is finicky: http://stackoverflow.com/questions/27641775/a-fatal-error-has-been-detected-by-the-java-runtime-environment-microsoft-sql

ok here we go I have a new error: Jan 08, 2016 4:11:52 PM com.microsoft.sqlserver.jdbc.AuthenticationJNI <clinit> WARNING: Failed to load the sqljdbc_auth.dll cause :- no sqljdbc_auth in java.library.path

that's likely the reason for the JNI failure. When you pulled down the sqlserver jdbc driver it should have also come with that sqljdbc_auth.dll file (a native Windows DLL). stick that file into your windows/system32 directory.

so that is what was causing my error from before

placed it in system32

if you run the app again it should progress beyond the failure to load the underlying native code.

though a "type 4" jdbc driver- what microsoft reports you are downloading from that url- is supposed to be 100% java and not have native code dependencies.

I think that’s among the reasons folks tend to prefer the tds driver

Yeah the driver I test with is pure Java (since I deliberately test connecting to SQL Server from a non-Windows machine).

we determined that the reason the type4 driver was pulling in native code was because of the "integratedSecurity" configuration- which uses native windows authentication and authorization mechanisms between the app and the database rather than name/password credentials

with integratedSecurity=truthy the driver expects to find an appropriate sqljdbc_auth.dll

what's likely happening is that the jdbc and native driver versions were different

leading to jvm death

Ah, interesting. Never run into that. Aside from testing, I generally avoid Microsoft anything :)

yeah, absolutely. striking though that for beginners, having clojure be a "hosted" language in this particular case leads to this perfect storm of nasty platform dependencies- the java/maven ecosystem, java's funky native platform integration, and the dependency nightmare that is windows

There are definitely some added issues using Windows, but I've actually run into way less problems with Windows dependencies on when developing Clojure than .NET.

Main problem I've run into is closing files - seems like things that work elsewhere don't actually close files properly on Windows.

And so far the jtds SQL driver with clojure.java.jdbc has been super solid

interesting. does it support that native authentication stuff? or only conventional username/password?

I've never tried, but according to http://stackoverflow.com/a/801113 it looks like it supports native auth as well

Though it mentions having a single sign on library installed, so may be some added complexity there