SQL Server Plug-in Requires TCP/IP?

[Craig Daniel]

First, I apologize if this has been asked and answered, but from what I’ve been able to find, I think this is still a valid question.

I have inferred from other posts that the SQL Server script plug-in (IA9 R2) requires that TCP/IP protocol be enabled on the SQL Server in order for the plug-in to function. Is this true? It appears to be true since I have a failing SQL script in my installer (connect error) which starts working after I enable TCP/IP on the SQL Server (which is on the same machine, by the way). If this is the case, why doesn’t the help say so? In case it matters, I’m using SQL Express 2008 R2 with Windows Authentication, and a default instance, running on Windows 7.

Assuming that’s true, what is one to do when installing on a machine where the TCP/IP protocol is not turned on and may, in fact, be turned off due to security policy? And after all, the default installation of SQL Server Express 2008 (and 2005) disables everything but shared memory.

My product uses SQL OLEDB to connect to the SQL Server, and it appears to work fine no matter how the SQL Server is configured – as far as protocols are concerned. Why can’t the IA plug-in do as well…?

[MichaelNesmith]

Did you read this sticky?
www.installaware.com/forum/viewtopic.php?f=2&t=5175

To ensure connectivity from computers that do not even have any database drivers/software installed, we have taken a network based approach. The default install settings for SQL Server as part of our application runtimes do properly enable network protocols.

However, if you want to try your approach, take a look at the Alternate SQL Server plug-in please:
www.installaware.com/forum/viewtopic.php?f=3&t=1637

That should work with your method.

[Craig Daniel]

Thank you Michael. I saw the first sticky, but not the second one. That first topic is the one that clued me in that network protocol might be the problem. But it didn’t really answer the question of whether TCP/IP is actually required. Hence my post. Anyway, now I know the answer: Yes. At some point I’ll give that Alternate SQL Server plug-in a try.

Embedding the SQL Server into my installer is really not a route I want to follow. From past experience, and things I’ve read, it’s likely to cause more problems than it solves. Plus we sometimes install SQL 2005, and sometimes 2008, depending on the customer.

[MichaelNesmith]

You could still embed and test for a specific instance's availability so you don't have to install if it has already been pre-installed. This is all built-in.

Of course, let us know how the alternative approach works out for you.

[Craig Daniel]

Well, I’m sorry to have to report that the alternate SQL server plug-in doesn’t work any better than the other one. It returns DATABASE_EXIST_ERROR rather than CONNECT_ERROR. And yes, the database already exists before this script runs. This is the simplest of scenarios: Default instance on the same machine, and the only protocol enabled on the SQL Server is shared memory.

I’m going back to my original plan B, which is to just handle all the SQL Server interaction from my custom exe file. It’s less convenient, but it works.

[MichaelNesmith]

It looks like the alternate plug-in did work for you, then? What you have is not a connection error.

Did you un-check the create database if absent option?

I am glad that you are able to connect, but please let us know if there's any issues with database checking/creation on the alternate plug-in so we can fix those too!