Re: Sql Server 2008 Express R2
Tanja Freeze
Sorry, no link, but one advice. Because we support Oracle and SQL Server, I know that getting fixes for the 'normal' Oracle database, is not something what I call fun. You have to pay for it, and if you have no tool which updates your Oracle system for you, it's a pain in the a.., if you ask me. Check out how the Oracle XE is supported with updates/fixes. I don't know, I only use the 'normal' Oracle (Developer) database.
If you are comfortable optimizing systems and are dba level in skills, I'd consider PostgreSQL. I do not consider myself a dba and have middling database skills and find SQL Server Express extremely easy to use. Also, I've had products exceed the limits of SQL Server Express - the transition to SQL Server Standard/Enterprise is seemless.
I realize that this doesn't matter at a technical level, but Larry Ellison buys jets and prostitutes with his profit. Bill Gates is solving problems of immense importance to humanity with his. All things being equal, I always prefer to give my money to Bill Gates.
If you really want a free alternative that is similar to MS SQL and supports growth should you need it, you could have a look at MySQL or PostgreSQL. SQLite also seems a good choice.Surely you can afford an old Linux server if you work in a company with 20 employees.
If your looking for a good RDBMS for a small project requring minimal knowledge for maintenance, SQL Server Express Edition is a good pick. The SQL Server Express Edition UI is much easier to understand than RMAN or the "easier"-to-use backup scripts included with Oracle Database XE which requires offlining your database.
Oracle Database XE is on my *** list. They recently released an ODBC driver for Linux that wasn't compiled properly (ld returns missing symbols for required ODBC functions) to be at all usable (10.2.0.4). With this kind of lack of attention to any reasonable amount of QA even for a 'free' product I would think twice about going down that road.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
These extra five steps are something I can't remember ever having had to do in a previous version of SQL Server, Express or otherwise. They appear to have been necessary because I'm using a named instance (myservername\SQLEXPRESS) on the server instead of a default instance. See here:
Under SQL Server Network Configuration > Protocols for Server > TCP/IP Enabled. Right Click TCP/IP and choose properties. Under the IP Addresses you need to set Enabled to Yes for each connection type that you are using.
On my installation of SQL Server 2012 Developer Edition, installed with default settings, I just had to load the SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSSQLSERVER and change TCP/IP from Disabled to Enabled.
I had the same issue with SQL Server 2014 locally installed named instance. Connecting using the FQDN\InstanceName would fail, while connecting using only my hostname\InstanceName worked. For example: connecting using mycomputername\sql2014 worked, but using mycomputername.mydomain.org\sql2014 did not. DNS resolved correctly, TCP/IP was enabled within SQL Configuration Manager, Windows Firewall rules added (and then turned the firewall off for testing to ensure it wasn't blocking anything), but none of those fixed the problem.
I had never realized that the SQL Server Browser service actually assisted the SQL Server in making connections; I was under the impression that it simply helped populate the dropdowns when you clicked "browse for more" servers to connect to, but it actually helps align client requests with the correct port # to use, if the port # is not explicitly assigned (similar to how website bindings help alleviate the same issue on an IIS web server that hosts multiple websites).
If the SQL Server Browser service is not running, you are still ableto connect to SQL Server if you provide the correct port number ornamed pipe. For instance, you can connect to the default instance ofSQL Server with TCP/IP if it is running on port 1433. However, ifthe SQL Server Browser service is not running, the followingconnections do not work:
If you are using SQL Server in a client-server scenario (for example,when your application is accessing SQL Server across a network), ifyou stop or disable the SQL Server Browser service, you must assign aspecific port number to each instance and write your clientapplication code to always use that port number. This approach has thefollowing problems:
Because only one instance of SQL Server can use a port or pipe,different port numbers and pipe names are assigned for namedinstances, including SQL Server Express. By default, whenenabled, both named instances and SQL Server Express are configured touse dynamic ports, that is, an available port is assigned when SQLServer starts. If you want, a specific port can be assigned to aninstance of SQL Server. When connecting, clients can specify aspecific port; but if the port is dynamically assigned, the portnumber can change anytime SQL Server is restarted, so the correct portnumber is unknown to the client. ... When SQL Server clients requestSQL Server resources, the client network library sends a UDP messageto the server using port 1434. SQL Server Browser responds with theTCP/IP port or named pipe of the requested instance. The networklibrary on the client application then completes the connection bysending a request to the server using the port or named pipe of thedesired instance
Well, god, it's actually really simple and maybe a bit foolish.When I tried to create a database and Visual Studio suggested the name of the SQL Server it gave me my Windows username and since it's actually the name of the server I went for it.
In reality it actually was my Windows username + \SQLEXPRESS. If you didn't change any settings this is probably yours too. If it works, stop reading; this is my answer. If it doesn't work maybe the name is different.
In my case the database was running on non standard port. Check that the port you are connecting is the same as the port the database is running on. If there are more instances of SQL server, check the correct one.
I'm doing overall upgrade planning on our infrastructure and saw SQL Server 2014 SP3 will get out of mainstream support in july 2019 identified which systems still run this version, Backup Exec server being one of them. Even if the extended maintenance support continues, MS will definitely limit their efforts for 2014 in favour of 2016 and newer. Thus I'd like to get all our DB instances upgraded in time - where possible to the same versions on the whole infastructure so that we have to keep an eye on less software version to keep patched and maintained.
The BE 20.3 admin guide mentions SQL Server 2014 Express SP2 as minmum requirement, however I haven't found an indication what newer versions of SQL Server (Express) are supported for the BKUPEXEC instance.
Ideally I'd like to upgrade to SQL Server 2017, then again if Veritas doesn't support new SQL Server for the BKUPEXEC instance it wouldn't be worth the effort. Hence my question about what versions are actually supported by Veritas in this case - and where I can find about.
Refer Backup Exec software compatibility list . Check the backup exec database repository section under Backup Exec Feature specific compatibility. This lists all supported SQL version on which BE can host its database.
If your company plans on migrating from SQL 2014 globally to 2016 or newer, currently upgrading a SQL instance installed and used by BE isn't going to be easy even possible right now. After some time working with the Veritas support I thought I could share some details nonetheless:
It's really disappointing to realize that in 2019 with the new BE 20.4 Veritas still ships SQL 2014 32-bit while BE itself has been 64-bit only since BE15 (that's 2 major releases by now). SQL Server 2014 is the last version made available for 32-bit at all and reaching end of mainstream support this year. All newer SQL Server releases are only made available in 64-bit editions. At some point Veritas will *have to* provide a working and supported upgrade path for its customers.
So far I've not been pleased with the Veritas support engineers who at some point even wanted to talk me into SQL 2017 wasn't supported (contradicting the SCL) or that they'd support SQL 2014 with BE even after MS ending mainstream support for 2014. (Veritas cannot backport fixes into MS SQL 2014, this would be possible with an open source DBMS)
Warnings ahead if you intend to upgrade the default BKUPEXEC instance:
Your only way to migrate any given MS SQL 32-bit instance according to Microsoft is to export/import or attach/detach from the old to a new instance at some point. At some point the software on the other end needs to know about possibly changed connection parameters.
In the case of Backup Exec the article I've been pointed at ( _US/article.100001771) has not worked for us. beutility at some point in the process detaches the BEDB database from the old install yet fails to re-attach onto the new instance. The end result was that the database was not attached to neither the old, nor the new instance and BE services would not start.
Had I not taken a DB dump with beutility before the attempt, would have resulted in further disruption of services. In our case the restore of the DB with beutility worked but the was left with the DB wrong owner of teh DB ending up in ODBC connectivity errors thrown by Backup Exec.
03c5feb9e7