I've actually just run into this exact same error, and this thread is the only result Google returned. We've set up OpenBD v1.4 on a Unix server for a client and set up a datasource to their SQL Server 2008 server. The datasource verifies fine, but queries result in the error "failed to verify remote server/socket @ _________:1433". We've checked to make sure SQL Server has port 1433 open (as apparently they no longer have it open by default), and I don't think it's the OS firewall settings of the SQL Server's OS because I can telnet to the machine on that port from our unix box.
- Matt C On Feb 15, 1:50 am, Elliot <[email protected]> wrote: > thanks Matt > > I'll mess around with this later, will just use my 1.3 instance for > the moment until i have more time resolve the issue. > > last effort for the moment - tried ODBC (and now get the error in the > admin) > > Could notverifydatasource: [Microsoft][ODBC Driver Manager] Invalid > string or buffer length > > if i put the wrong password in i get the right error - so it is > reaching the server! > > Oh well will get back to it later. > > On Feb 15, 3:52 pm, Matthew Woodward <[email protected]> wrote: > > > > > On Mon, Feb 14, 2011 at 8:22 PM, Elliot <[email protected]> wrote: > > > All listed instances on the same machine (where SQL Server is running) > > > - each bound to a different listening port (so they can function at > > > the same time). > > > OK, but I was asking if the working instance of OpenBD and the non-working > > instance of OpenBD are running on the exact same Vista machine with the > > exact same settings (firewall, AV software, etc. etc.) since if that isn't > > the same it might indicate why one can connect and another can't. > > > Have you tried telneting from the box in question to port 1433 on the SQL > > Server? If the datasource verifies chances are there aren't any connectivity > > issues but I always go back to basics to troubleshoot. > > > I never used named instances on SQL Server, and IIRC there was a SQL Server > > driver update between OpenBD 1.3 and 1.4, so maybe there's some difference > > in how named instances are addressed? > > > Have you tried using the "Other" datasource type and using the appropriate > > JDBC URL to connect to the SQL Server instance as an experiment to see if > > that works? > > > I've also seen cases where if you created the datasource and then edit it > > later, if there are open connections the datasource doesn't get updated > > until you restart OpenBD. Have you tried creating a brand new from scratch > > datasource? (Maybe that's where you started, just another thing that came to > > mind.) > > > > Are there any other cahanges to the jetty/openbd config required (i > > > changed the port from 8888, to 8884). The admin runs and identifies > > > correct instance. > > > There shouldn't be any changes *required* to the ready2run version to get > > this working, no. > > > Unfortunately I don't really have an easy way to test named instances in SQL > > Server but if it comes to that I can fire up a Windows VM, install SQL > > Server, replicate your setup, and see where I get. > > > -- > > Matthew Woodward > > [email protected]http://blog.mattwoodward.com > > identi.ca / Twitter: @mpwoodward > > > Please do not send me proprietary file formats such as Word, PowerPoint, > > etc. as attachments.http://www.gnu.org/philosophy/no-word-attachments.html- > > Hide quoted text - > > - Show quoted text - -- official tag/function reference: http://openbd.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
