I need to connect to a database server mssql.
I used the example project MSSQLServerExample but I always get this error at the connection:
“SQL Server Native Client not installed. Download the ‘SQL Server Feature Pack’ from www.microsoft.com.”
I already have installed on the client on which the application runs the “Microsoft SQL Server Native Client” version 9.00.4035.00.
From the client I can connect to the database with SQL Server Management Studio Express.
Xojo version is 2015r1
O.S. in Windows 7 professional SP1
Check out this thread, Claudio. link text
Make sure you go beyond the response marked as “Answered” and read down into the rest of the replies. In the scenario talked about in the thread, Louis chose to go with ODBC connection, but there are other alternatives. You’ll see my response about half way down the thread and I solved my situation without having to go with ODBC. BTW … I’m using the MBS SQL plugin.
Just to be perfectly clear, I use OLEDB, not ODBC. I find OLEDB faster than other methods, but the clear drawback is that I have to use a Windows host. As soon as you want to work in an other environment than Windows, then OLEDB is not an option.
On my to-do list, I have an item to convert my MSSQL databases to Postgre. I keep postponing, partly due to the fact that I will need a value added reason to do so, and partly because I have a sizeable code base of stored procedures that would need to be converted to postgre functions. Call this lazyness if you want.
Oops! Sorry about that, Louis. That’s one of those I was replying quickly to the OP before a conference call I had to be on and although my mind said “OLEDB”, my fingers typed “ODBC” … I think they call it “getting old” ^^
No offense Don, it was also worth mentioning clearly the limitations of my preferred approach.
For what it’s worth, I also find that senile moments occur more and more often. It started to happen when colleagues began to be the same age as my kids. Now that they’re younger than my kids, it seems to be worse. The empiric proof is there: senile moments are caused by the youth of one’s colleagues.
That, Sir, is PRECIOUS! You could not have described it any better.
That’s why I suggested Claudio read down through all the responses … that issue ("SQL Server Native Client not installed … ") seems to have more than one cause and more than one solution, depending on the user’s scenario and requirements.
Reopening this thread (I’ve also looked here: ) without success.
I’m trying to connect to a SQL Server 2014 instance running on Windows Server 2012r2. My app is 64-bit, built with Xojo 2016r1.1, running on Windows 10 Pro, Version 1511, Build 10586.420.
I get this message when trying to connect using the MSSQLServerDatabase:
“SQL Server Native Client not installed. Download the ‘SQL Server Feature Pack’ from www.microsoft.com.”
After installing all of these, I still get this message.
Before I give up and switch to Christian’s plugin, can someone enlighten me as to EXACTLY what I’m supposed to install to make Xojo work with SQL Server databases?
[quote=179452:@Louis Desjardins]
On my to-do list, I have an item to convert my MSSQL databases to Postgre. I keep postponing, partly due to the fact that I will need a value added reason to do so, and partly because I have a sizeable code base of stored procedures that would need to be converted to postgre functions. Call this lazyness if you want. ;-)[/quote]
OR “lock in” which is what vendors want
From my perspective, “lock-in” will happen with any technology that one decides to adopt. One could argue that once one has a sizeable code base of Xojo apps, one is locked-in with Xojo, since that code is not readily portable to, say, Visual C++, Objective C or some other such language. I could go on, but the point is made.
My take on technoilogy is that it needs to do the work based on the task to be done and based on the primary audience that the task is targeting. I am certainly not religious about it. Moving to Postgre is still on my agenda and I have a few proofs of concept under way. Now that MS SQL Server is being ported to Linux, I find that the urgency to move to a platform independent RDBMS is lesser. My preferred platforms are Windows and Linux (I dont like hardware lock-in that comes with Apple products. I am of the opinion that software is the future, not hardware. In that sesnse, locking-in with Apple hardware means taking a very uncertain turn. - I am certain that I will be stoned for this assertion, so be it.)
I am sure that future evolution of various technological tools and platforms will bring yet unknown choices that will further modulate my decisions.
DB’s should, IMHO, be data stores not “business logic repositories” (which is often how stored procedures are used)
Once you have to “port” a sizeable body of stored procedures from one DB to another you’ll find out just how radically different their capabilities are. And in some case that what you can do in one you cant do in another so you have to rethink whatever process/functionality was in that stored procedure.
But, I’m not religious about it either.
Just saying that in the end a 3 tier architecture gives you a nice separation of concerns and IF you ever need to swap from one db to another rewriting the SQL is a lot simpler than rewriting the SQL AND stored procedures.
Charles, I have not experienced the issues that you are having. I am trying to reproduce your problems in my lab, but so far, I cannot. Hopefully, someone else will be able to provide a solution.
Norman, you make a good point. In fact, my stored procedures are usually relatively simple SQL. I will include logic in order to reduce the complexity on the application side, but not to replace application logic. I use stored procedures in place of prepared statements. Still, the differences between SQL server and Postgre, the case discussed, and even the little logic placed in my procedures, are sufficient to make the exercice not trivial. I have to give you this point.
