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 tend to look at it the other way around. Supporting a database takes effort to test. So any company would want to choose the databases that most of their present and future customers would use. I don't see many SQL Server Express databases in enterprise data centers.
However, I would have to image that there are numerous smaller or younger companies that don't want to put out the expense for a standard SQL Server, Oracle etc. SQL Server Express allows up to 10gb per database and works well for smaller environments. Requiring a relatively expensive database platform increases the base cost of Jira considerably.
True, but they may want to move to SQL Server Standard or Enterprise as they grow. This would provide flexibility for budget, etc. They may also have SQL Server in their environment for other applications.
Anway, I know there are other options. I just don't understand any technical reason why it is not supported. If there is a product positioning, marketing or other reason, I would just like to understand.
I don't think it's marketing or positioning, or even technical, just about reach and cost. To fully support a database, Atlassian have to commit to fully testing the applications on it. I suspect only a small amount of the user base is interested in MS SQL Server Express, so there's very little point in investing in support for it.
I don't have any numbers but do see that SQL Server Express is used in third party applications quite a bit. They use it and deploy their solutions with it to keep the cost of their solution to a minimum. If they have customers with mid to large data or processing power needs, they step up to another version of SQL Server.
My guess is that your comment and Matt's comment above are correct and it is a testing issue. However, I have never run into an issue running something on Standard or Enterprise that won't run on Express. When I say that I'm taking about stored procedures/TSQL, etc. I would doubt that their is anything in Jira that takes advantages of features not found in Express. If JIira use SQL Server Agent or SSIS, that would not be available in Express. I have not seen that it uses either of these capabilities as they would not be available in other database platforms.
"Starting with SQL Server 2012, these memory limits are enforced only for the database cache (buffer pool). The rest of the caches in the SQL Server memory manager can use much more memory than is specified by these edition limits. For example, a SQL Server 2012 Express edition can use only a maximum size of 1.4 GB for its database cache. Other caches (such as the procedure cache, the metadata cache, and so on) can consume memory up to the size specified by the "max server memory" configuration."
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.
d3342ee215