31–40 of 48 posts
Yay... Isnt everyone using jTDS anyway because it is reliably faster? https://social.msdn.microsoft.com/Forums/en-US/36e7b9cf-5bc5... http://stackoverflow.com/questions/7848213/why-is-jtds-faste... Edit: seems like they fixed their abysmal performance after 5years in jan 2016; see stackoverflow comment.
Earlier quoted context omitted.
> the bane of my existence This reminds me far too much of the .NET DB2 drivers. What a steaming pile, not to mention having to navigate the labyrinth of the IBM download site to even find it in the first place.
You know what's worse? DB2 for iSeries. Pisses me off to no end that pulling JTOpen from Maven is crazy easy, but if you want to access your data from any other language prepare to shell out thousands of dollars for "DB2 Connect" (per server!) because it's totally incomprehensible that even though you've already payed through the nose for IBM i that you shouldn't be charged for accessing the data anywhere else.
"Hi $BIG_COMPANY, we'd like to expand our usage of $SOFTWARE that we've already got a $BIG_MONEY license for. Where can we get client drivers for a new app that will use it?"
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
"Hi $BIG_COMPANY, to clarify, we're already paying $BIG_MONEY for a license for the server and we'd like to expand our usage of it. That means in the longer term we'd be more entrenched into using it and would likely renew your contract."
"Hi $CUSTOMER, that's great news. Send us a check for $MORE_MONEY and we'd be happy to help."
How did people use this before if it wasn't in the Maven Central Repo? I know it's possible to not use mvn, just wondering what people did in cases like this where a possibly major component in the stack was unavailable. Most big stuff in Java can be found in mvn, and if not we often end up using an alternative. But that's not so easy for a driver.
Here's a nice article explaining how to do it: https://devcenter.heroku.com/articles/local-maven-dependenci...
Earlier quoted context omitted.
> Microsoft has been open-sourcing a lot lately, but it seems to be mostly "peripheral" software... How is .NET Core peripheral software? If anything it enables developers with C# codebases to move away from Microsoft's commercial products.
And they've open sourced a lot more than just .NET Core. https://github.com/Microsoft/dotnet
I remember we had once revert to java 6, because we couldn't get connectivity in Java 7 with SQL Server through their JDBC Driver... It took days to figure it out...
How did people use this before if it wasn't in the Maven Central Repo? I know it's possible to not use mvn, just wondering what people did in cases like this where a possibly major component in the stack was unavailable. Most big stuff in Java can be found in mvn, and if not we often end up using an alternative. But that's not so easy for a driver.
Finally! Having dealt with many database drivers over the years, I can say first hand that closed source drivers are the bane of my existence. The only thing worse than running into a deep-in-the-stack bug in a database driver is one that you can't correct, let alone debug properly. Regardless of your views on closed source software on the server side of things, it's a disservice to your customers to not have open so…
> the bane of my existence This reminds me far too much of the .NET DB2 drivers. What a steaming pile, not to mention having to navigate the labyrinth of the IBM download site to even find it in the first place.
Porting a .NET application build for MS SQL to DB2 and dealing with all the ... pecualiarities of the DB2 driver is something I will hopefully never have to do again.
Finally! Having dealt with many database drivers over the years, I can say first hand that closed source drivers are the bane of my existence. The only thing worse than running into a deep-in-the-stack bug in a database driver is one that you can't correct, let alone debug properly. Regardless of your views on closed source software on the server side of things, it's a disservice to your customers to not have open so…
Not so much anymore? The tendency is towards smarter clients and possibly dumber servers.
cf Kafka
Also fast switchover in Oracle's JDBC drivers requires some code outside what is required by JDBC api.
How did people use this before if it wasn't in the Maven Central Repo? I know it's possible to not use mvn, just wondering what people did in cases like this where a possibly major component in the stack was unavailable. Most big stuff in Java can be found in mvn, and if not we often end up using an alternative. But that's not so easy for a driver.
I have similar library and I use the following approach. I have "lib" directory in the project and I have those jar files there. Also there's simple install.sh script which calls "mvn install:install-file" for every jar-file. So developer has to run install.sh script once and he's done.
Yay... Isnt everyone using jTDS anyway because it is reliably faster? https://social.msdn.microsoft.com/Forums/en-US/36e7b9cf-5bc5... http://stackoverflow.com/questions/7848213/why-is-jtds-faste... Edit: seems like they fixed their abysmal performance after 5years in jan 2016; see stackoverflow comment.
The jTDS project is dying, there has not been a new release in over 3 years despite some pretty significant bugs. https://sourceforge.net/p/jtds/discussion/129584/thread/050f...
But I just cant stand the loving hype for MS here. They gave out such horrible and dog slow drivers to their paying customers that people reverse engineered the protocol and wrote their own. And it still performs very well.
Now that MS publishes this codebase (which should have been standard, or at least best, practice), they get showered with love.
Like an abusive relationship where one is happy and extatic if the abuser is reasonably nice for a day.