I've seen that a lot. When I import Drupal databases, I learnt to use its Backup and Migrate module instead, it works flawlessly. Downside is you need to do clean Drupal installation first, but that basically is just creating blank database and putting brick on enter key.
There used to be a lot of databases like SQLite. Often called database engines. dBase was probably one of the first.
Later Microsoft Jet engine (aka Microsoft Access) became popular when Visual Basic ruled the world.
Basically it's a one user database. You can have more than one user but it's done by multiple users accessing the same database file.
Or by having an application on top that accessing the file and shares it out. That thing can be called a "database management system" or any application, really.
All databases use database engines. MySQL, for example, isn't a database. It's a database management system. It uses one or more database engines to talk to the files on disk. MyISAM and InnoDB are two database engine options for the MySQL platform.
At the end of the day, all databases work like SQlite. You can easily build your own database management system that uses SQlite as the engine and it could work just like MySQL or Oracle or SQL Server. Those are all single users to a file, under the hood. They just have the "multi-access" management built into an extra layer, instead of letting an application handle it.
But for most things, you only access a database from a single app anyway, so that extra layer is often unnecessary as it is redundant. Just adds overhead.
Since there is no inner or outter join specified, inner join is obviously being used where 'join' is specified (outter join having to be explicitly defined where an outter join is needed). How come you explicitly specify 'inner join' at the bottom when you could just use 'join' again as your inner join?
Obviously join and inner join accomplish the same thing, just curious why one is not explicitly defined and the other is.
I expanded on something done by someone from the osTicket team. it was some weird stylistic choice that they made and I just followed.
Are the two SQL servers sitting side by side? If not, shared storage and low latency for it's use would be super expensive.
Though I do wonder how their DR plan works if there isn't a cluster for the DB, what purpose does the second server serve? Warm spare?
Yes the servers are side by side, basically just sits there, and when a new site is created on SP side, run the script which mirrors the new DB created on server 1 to server 2. Eventually they were planning to introduce the witness server once our testing is complete and then enable auto failover. The downside here is that someone need to manually run the script for db mirroring of new databases
So the big thing here is that the databases are not mirrored, just the framework (schema) is at creation time. Very different from mirroring or clustering at that aspect level.
Yes, we've told them this won't work and asked them to look at a clustered setup. Since the licenses are already in place and is SQL standard no option for Always-On. I want to know what would be the drawbacks for the clustered setup, as for sure there are some more advantages on Always-ON compared to the clustered setup.
Won't work... for what? What's the end goal?
Won't work: Current stage its 2 separate DB servers and mirroring needs to be done by executing a script whenever there is a new db is created by SP.
End Goal: A fully automated failover setup giving high availability for the SharePoint solution
What they are doing is unrelated to their end goal. How does mirroring database creation help with failover. There isn't even a first step in preparing for a failover here. What is going on is totally something different.