Dbtext for SQL tests out okay on SQL Server 2012. My specific test environment was:

• Client
  • Windows 8 x64
  • Inmagic Dbtext for SQL 13, SQL authentication
• Server
  • Windows Server 2008 R2
  • SQL Server 2012 SP1 Standard (11.0.2100)
  • Mixed mode enabled
  • TCP/IP protocol enabled
  • Firewall enabled, TCP 1433 port open

 

Many of our clients have been using the same server to host their Inmagic software and other database and collection management systems for many years now. The software may have been upgraded and modified over the years and the server may now contain an undocumented collection of no-longer-in use files, databases and older versions of software. It may be running an older OS such as Windows Server 2003 and the hardware may be getting long in the tooth as well.

Given all of the above, it may very well be time for some server retirement planning. It’s always better to replace a server while it’s still running than to have it fail and have to scramble to get a new one going with all your applications and data. Assuming you have good backup procedures in place, you should be able to recover from a failure, but it’s still better to replace in advance.

The first step in a server renewal process is to audit and document the current server, looking in particular at:

• the applications and data currently installed;
• users who need access or may have desktop components on their workstations; 
• backup procedures; and
• folder permissions.

With a clear picture of the current environment, the next step is to provision a new server. The trend these days, at least among organizations of a certain size, is to spin up a new virtual server dedicated to a particular workgroup or business unit. This is usually a Windows 2008 server, but we expect Windows Server 2012 to become the norm soon. Virtual servers do require a license for the operating system, but as they are virtual, there is no new hardware required.  Multiple virtual servers can be hosted on one physical machine and can be readily moved to new hosts, simplifying ongoing management.

The next step is a fresh installation of Inmagic DB/TextWorks, WebPublisher, Genie and other software on the new server, and migration of data and specific configuration settings or applications. Andornot often assists clients with planning and implementing this step. 

With the new server running, be sure also to ensure that appropriate backup procedures are in place, and tested.

This approach gives you a well-built, correctly-installed, fresh, reliable platform on which to work, using the latest versions of all your applications.

An alternative is to outsource some or all of the software hosting to Andornot. Our data centre hosts both Inmagic and other applications at costs competitive with managing your own infrastructure.

This can also be a time to look at adding new features or programs to improve your service delivery. For example, a discovery interface style of search engine for your data provides the features that users now expect of web applications.

As always, contact us for advice or our help planning and performing any upgrades. We can help with both Inmagic and other applications and data on the server. Even if you don’t need to replace the server itself, we can help you organize and clean up your Inmagic files and textbases, test your backup procedures, and ensure the server is in good shape, both now and for a future replacement time.

 

If you're attempting to use Microsoft's Database Publishing Wizard you might run into an error like the following (if you're running SQL Server Express 2005 - don't know if you will run into it with SQL Server 2005 Standard etc.):

This wizard will close because it encountered the following error: Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.SqlServer.ConnectionInfo)

If you do, just download the x64 version of Microsoft SQL Server 2005 Management Objects Collection located here. This post pointed me in the right direction as the possible solution suggested does in fact resolve the issue.

A couple months back when I first switched my primary developer machine to Vista, I wanted to connect to a SQL Server 2000 instance on my WinXP Pro virtual machine (Virtual PC 2007). It took a bit of digging to figure out how to a) even do it with WinXP to WinXP and then b) do it with Vista as the host OS.

Typically, it's an easy thing to set up your virtual machines to talk to each other, and also talk to the host machine, but to get the host machine to be able to talk to the virtual we need to go a little further by configuring a Microsoft Loopback Adapter. Using the Microsoft Loopback Adapter opens our Virtual Machine only to the host. To do this in Vista, do the following:

1. Install a Loopback Adapter
   1. Open Control Panel
   2. Vista caveat: switch to Classic View to "Add Hardware"
   3. In the "Welcome to the Add Hardware Wizard", click Next.
   4. Select "Install the hardware that I manually select from a list (Advanced)" and click Next.
   5. Scroll down and select "Network adapters" and click Next.
   6. Select under Manufacturer "Microsoft" and then under Network Adapter "Microsoft Loopback Adapter" and click Next.
   7. Click Next and Finish.
2. You can manually configure your IP Address for your adapter, but you can just let the loopback adapter get an auto configuration IP address from your router's DHCP.
3. In your Virtual PC Console, choose settings for the applicable virtual machine, and then choose "Networking".
4. Select the now available "Microsoft Loopback Adapter" (note that your virtual machine will need to be off, not in a saved state, in order to make this change).
5. Turn on your virtual machine and once it's booted up, verify that the Microsoft Loopback Adapter has installed its routing in your host PC's route table by going to a command prompt in the virtual machine and typing "route print".
6. In the case of a virtual machine running WinXP, make sure you've allowed file and print sharing in the virtual machine's firewall settings.
7. Open a command prompt and run ipconfig to find out what your virtual machine's IP address is (note that as we have not configured the Microsoft Loopback Adapter to allow the virtual machine to connect to the outside network, your task bar network icon will warn you that you have limited connectivity – thus the need to run ipconfig from a command line to see if the virtual machine even has an IP address assigned).
8. Check whether your host machine can now communicate with the client virtual machine by pinging it's IP address by opening a command prompt in Vista and typing "ping 169.254.166.12" where you enter your applicable IP address.
   c:\>ping 169.254.166.12
   Pinging 169.254.166.12 with 32 bytes of data:
   Reply from 169.254.166.12: bytes=32 time=1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Ping statistics for 169.254.166.12:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
   Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 1ms, Average = 0ms
9. And voila, you've now successfully networked your host machine to talk with your client virtual machine.

If you still want internet access for your client virtual machine, do the following:

1. Open your Network and Sharing Center
2. Click Manage network connections in the left hand navigation bar
3. Right-click the loopback connection and select properties.
4. In the sharing tab, enable “Allow other network users to connect through this computer's Internet connection.

This "should" work, but I initially encountered "an error occurred while Internet Connection Sharing was being enabled." However, it resolved soon afterwards all by itself.

The article that was the biggest help in getting the above in place was http://www.governmentsecurity.org/archive/t10129.html

UPDATE: Change to post title.