I use a Nikon D7100 camera and Nikon's Capture NX2 software. Recently Nikon have released a beta of some new software (here) they've got another company to produce and when it goes live Nikon will stop supporting Capture NX2. I wrote about the problems this will cause me and thousands of others at Nikon Capture NX is dead, Nikon have stolen our property and left us high and dry. Now it appears the subject of that post might be a bit over the top (I was really annoyed when I read the beta announcement of the new NXD beta) but the fact remains I (and countless others) have got thousands of hours of image editing that could potentially be lost. What is the problem?
The thread on dpreview that started this off is at here. Basically, Nikon have got Silkypix to write a new editor (NXD) for Nikon and will stop supporting Capture NX. You can try the beta of NXD here. The beta feedback page is here and the official comments include things like:
I just released the 3rd development release of DBD::ODBC (1.39_3). Apart from a few bug fixes and other changes (see below) this release adds support for MS SQL Server Query Notification. Query notification allows an application to request a notification from SQL Server when the results of a query change. Once set up you can block on an execute call waiting for the query to change. Here is an excerpt from the pod:
I have just uploaded DBD::ODBC 1.47 to the CPAN.
This release does contain significant changes in behaviour for unicode builds of DBD::ODBC so I hope when I warned you months ago you tested it.
Thanks to everyone on the dbi-dev list and irc that helped me work my way through the unicode issue.
I'm now going to sit back and wait for the usual rush of reports from everyone who didn't test it.
See below for changes since last full release.
Full release of the 1.46 development releases.
Back in 2011 I wrote Faster HTTP usage. At the time Curl was the winner for the way I use HTTP. Since then a few more HTTP client modules have appeared on the CPAN and I was nudged by Tim Bunce to repeat my testing with the newer Hijk and HTTP::Tiny.
I have owned a Nikon D3100 for a few years now. I generally have it set up to take nef/raw images and in camera processed jpg files so I end up with a load of files on my SD card called _DSCNNNN.NEF and _DSCNNNN.JPG. I sometimes edit the raw/nef files in Nikon capture NX and write a new JPG out as _DSCNNNN_copy.JPG and upload it to picasa or Nikon or google plus.
This morning I had a printer head jam on my Kodak Hero 5.1 and despite searching on the net I could not find anyone with a solution except a youtube video for another Kodak printer.
Obviously, you follow this at your own risk.
I've just uploaded DBD::ODBC 1.46_2 to the CPAN. In the process of writing Some Common Unicode Problems and Solutions using Perl DBD::ODBC and MS SQL Server and github repo I discovered a serious bug in the way DBD::ODBC can attempt to insert unicode characters into char/varchar/longvarchar columns. This experimental release fixes that issue but it does mean this release contains a significant change in behaviour. Since 1.46_1 yet another unicode fix was added too.
I've just uploaded DBD::ODBC 1.46_1 to the CPAN. In the process of writing Some Common Unicode Problems and Solutions using Perl DBD::ODBC and MS SQL Server and github repo I discovered a serious bug in the way DBD::ODBC can attempt to insert unicode characters into char/varchar/longvarchar columns. This experimental release fixes that issue but it does mean this release contains a significant change in behaviour.
I've just uploaded DBD::ODBC 1.45 to the CPAN. As always I'd draw your attention to a few small changes in behaviour. The changes since 1.43 are listed below but I need to warn you about an upcoming change first.
WARNING - PLEASE READ:
The next development cycle of DBD::ODBC will contain signficant changes to the way unicode strings in your Perl scripts are inserted into CHAR and VARCHAR columns. In an attempt to write up exactly how this all works (see https://github.com/mjegh/dbd_odbc_sql_server_unicode and http://firstname.lastname@example.org/msg07364.html) I have discovered that unicode strings are not being inserted into CHAR/VARCHAR columns correctly in the unicode build of DBD::ODBC. There may also be changes to how unicode strings are read back from the database but I have not evaluated that yet.
Please make sure you keep an eye out of DBD::ODBC development releases 1.46_N and ensure you test them before the next full release is made. In the mean time if you are using unicode with DBD::ODBC and have any comments, have hit any strange issues or are using any workarounds I strongly urge you to contact me now before I get too far into these changes.