@scottalanmiller said in Get Alert Whenever There is MS SQL Server Access:

It's a production database so there should be an email when the application connects and absolutely no user should ever, ever, ever be able to log in unless it's an admin doing an emergency backup and/or restore (likely alerts would be off during a restore.)

I cannot imagine a MS SQL Server based client-server application that does not make a billion DB calls all day long. So you will have to exclude that system user from being audited.

@scottalanmiller said in Get Alert Whenever There is MS SQL Server Access:

There's no user ever authorized to just connect.

The application user is always connecting. Repeatedly.

@syko24 said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

@scottalanmiller said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

@syko24 said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

There is a product out there called QBox that allows you to lock and sync the file with multiple locations. The downside is that remote users can only access the file when the local users have closed out of QuickBooks. Kind of a neat product but again not ideal when you need multiuser access all the time. The best solution in my opinion is an RDS server with the QuickBooks data file stored on the RDS for best performance.

As the QuickBooks desktop products seem to be coming closer and closer to an end, I agree that the online version is likely the best way to go. Part of the problem is that users have been using the desktop version for so long that the online version becomes very foreign to them and most want to return back to the desktop version.

https://www.coraltreetech.com/how-qbox-works

Yeah, that's not multiuser but rather "rapidly changing and coordinated single user". Could be a useful solution for some, though. You can do this with most products. NextCloud for example.

From the use case I've seen that is correct on being a single user product. I did watch the video on the link I posted and it does look like you can still do multiuser as long as the users are all on the same network. The remote user can only access once all the local users are out of the file and it has done it's sync. The file locking is automatic as well which is nice. It basically prevents the outside user from accidently overwriting your changes.

Sure, you can always bypass the sync and do local multiuser, but the humans have to manage that.

@scottalanmiller It makes sense they can't because of the nature of their static Database.

Thanks, seen this a few times recently.

@Matthew-Grieve said in How to Backup Patterson Dental EagleSoft Software:

https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.12.0.1/dbadmin/da-backup-dbs-5615940.html

SQL Anywhere Volume Shadow Copy Service (VSS)
SQL Anywhere is compatible with the Microsoft Volume Shadow Copy Service (VSS). You can use VSS to create point-in-time snapshots of entire disk volumes or volume sets and to make copies of files that are open for exclusive use by applications such as the SQL Anywhere database server. VSS is supported on 32-bit Windows XP operating systems and on 32-bit and 64-bit editions of Windows 2003 and later operating systems, including Windows Vista.

By default, all SQL Anywhere databases can use the VSS service for backups if the SQL Anywhere VSS writer (dbvss12.exe) is running. You can use VSS without the SQL Anywhere VSS writer to back up databases. However, you might need to use the full SQL Anywhere recovery procedures to restore those databases. To prevent a database server from participating in the VSS service, include -vss- when starting the database server. Alternatively, you can use the Service utility (dbsvc) for Windows to specify when the VSS service is started.

How VSS works with SQL Anywhere:

Your backup application sends a command to VSS to take a snapshot.

VSS issues an identify command to the SQL Anywhere VSS writer (dbvss12.exe).

VSS issues a prepare to snapshot command to suspend all transactions and write all modified pages to disk on all databases on all database servers. If transactions are not suspended on a database within 10 seconds, the snapshot might contain uncommitted transactions and full recovery may be necessary.

VSS issues a freeze command to checkpoint and then suspend all activity on all databases on all database servers. Each SQL Anywhere database server waits a maximum of 60 seconds for all databases to suspend all activity. Typically, this process takes a few seconds.

VSS issues a thaw command to the SQL Anywhere VSS writer to resume all transactions on all databases on all database servers.

In rare circumstances, SQL Anywhere might be unable to suspend transactions or complete a checkpoint within the maximum time allowed by VSS. If this occurs, you must use the transaction log file and the full recovery process to recover the backed up database.

We use StorageCraft ShadowProtect with ImageManager to take hourly incrementals of our clients server volumes. Never had any issues.

That's true when you have SQL Anywhere running as a service. But when embedded, there is nowhere for the VSS to link against. Are you sure that this process will work with EagleSoft and their implementation of SQL Anywhere? I know that a full blown SQL Anywhere can do it. But that's not the issue here.

Thank you for the heads up @scottalanmiller

@jaredbusch said in Restoring a Windows MS SQL Server Database to Linux With Move SQLCMD:

@scottalanmiller I have not had to do that before with a normal backup to a .bak and then restore. Not some an place move like it seems you are doing.

Happens if going to a space with a different storage layout. If you are coming from Linux you are probably fine. But Windows injects the drive letter into the path (obviously) and so going from one machine to another that doesn't keep identical storage path names causes the issue.

@scottalanmiller said in Multiple Virtual Disks and Application Performance:

Remember.... just because you are virtual does not imply that your storage is virtual, nor does virtual storage imply that the storage will be shared between workloads or VMs. None of that is implied or suggested in going virtual. You still maintain all proper storage management decision making when virtual as you did physical. You don't get to give any of that up.

In restrospect, I probably ought not have included the System Center Dude stuff in the discussion, since it seemed to just cause confusion about what I was curious.

You still maintain all proper storage management decision making when virtual as you did physical.

I believe this is the greatest takeaway from the discussion. Regardless if the environment is like the one I'm in where ultimately one physical storage device is hosting all of the virtual storage within the VMs.

@Romualadas said in Error After Firebird 2.5.9 Update:

@scottalanmiller
Tried your link. Results:
yum install /tmp/FirebirdSS-2.5.9.rpm
Loaded plugins: fastestmirror
Examining /tmp/FirebirdSS-2.5.9.rpm: FirebirdSS-2.5.9.27139-0.amd64
Cannot add package /tmp/FirebirdSS-2.5.9.rpm to transaction. Not a compatible architecture: amd64
Error: Nothing to do
Server architecture:
Kernel and CPU Linux 3.10.0-1062.18.1.el7.x86_64 on x86_64

Looks like their packages are bad at this point. You definitely have the right, matching architecture there. Seems that they are having a lot of problems these days. It's such a niche product, I'd be super wary of every using it in production or any software the depends on it. Using it as an option, sure, but requiring it I'd consider a non-starter. Absolutely no one supports it.

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.

@Pete-S said in How to Rename a Column in SQLite Database:

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.

@scottalanmiller

I like your 53 mins intros, but that said you cover and reach all the important parts. I wonder what will be deep dive session how long will that video be.

@Obsolesce said in UREs Strike InnoDB on MySQL:

@scottalanmiller said in UREs Strike InnoDB on MySQL:

@Pete-S said in UREs Strike InnoDB on MySQL:

Step one is to remove the drives and clone them with dd or recovery tool to a new drive.
You could probably recover 99.9% of the data - if you want.

As you can guess from all of their previous issues, they don't want to pay for any recovery, they just want it magically fixed for free. They don't own any storage onto which to clone it, either.

Then what is the point of any of it? It appears to have zero value to the business.

I said that to them.

@dafyre said in PATH Error with TimeScaleDB-Tune on Fedora 30:

then why are you even using it?

Capacity Planning, for example.

I've done both. I tend to like MariaDB / MySQL better because that is what I'm more comfy with.

So, easy fix, the ca_stag2 was a staging DB that was not needed and was not current. The whole thing appears to have corrupted. So I simply "moved" that entire directory to /tmp (just in case I had to put it back) and then MySQL could fire up.