Navicat Blog

Using a Case Statement in a Where Clause Jun 23, 2020 by Robert Gravelle

A short time ago we were introduced the incredibly useful and versatile Case Statement. In that blog, we employed the Case Statement as most DBAs and developers do, in the SELECT clause. Another way to use the Case Statement is within the WHERE clause. There, it may be utilized to alter the data fetched by a query based on a condition. Within that context, the Case Statement is ideally suited to both static queries, as well as dynamic ones, such as those that you would find inside a stored procedure. In today's blog, we'll create a SELECT query in Navicat Premium that returns rows based on the values of another field.

Troubleshooting Slow Query Execution with Navicat Monitor 2 Jun 11, 2020 by Robert Gravelle

With so many factors to consider, uncovering the root cause(s) of slow query execution takes an organized approach. Luckily, with a bit of effort, you can pin down an issue to one of the more common culprits by checking up on a few things. In today's blog, we'll learn how Navicat Monitor 2 can help you get the the bottom of slow query execution - fast!

Counting String Occurrences in SQL June 5, 2020 by Robert Gravelle

Although not as proficient at string manipulation as procedural programming languages such as Java, C++, and PHP, SQL does provide many functions for working with string data. These may be employed to trim off extra spaces or characters, determine how long a string is, and concatenate several field values together. String functions are well worth becoming acquainted with as they can help make your code more effective and readable. In today's blog, we'll learn how to count the number of string occurrences within a char, varchar or text field using a couple of native SQL string functions.

MySQL Default Values: Good or Bad? - Part 2: When To Use Them May 28, 2020 by Robert Gravelle

Part 2: When To Use Them

You probably already know that setting a default value on non-null columns helps get rid of those pesky "Field 'xyz' doesn't have a default value" errors. Hopefully you're also aware that keeping error messages at bay is not in-itself a valid reason for supplying default values. There are many reasons for providing default column values - some good, and some, less so. Part 1 explored the ramifications of MySQL's Strict SQL Mode, as well as how to view and set it using Navicat for MySQL 15. In today's follow-up blog, we'll tackle when to use default values, and how to come up with good ones.

MySQL Default Values: Good or Bad? - Part 1: Strict SQL Mode May 22, 2020 by Robert Gravelle

Part 1: Strict SQL Mode

Getting errors when you don't supply a value for a non-null column can be an immense source of frustration. There's a way to minimize the occurrence of such errors by setting a default value for those columns. Seems like an easy fix, but, as in all things, the devil's in the details. You have to be careful that you don't add a bunch of generic - and useless - data to your tables just for the sake of making INSERTs easier. In today's blog, we'll learn about the ramifications of MySQL's Strict SQL Mode, as well as how to view and set it using Navicat for MySQL 15. In part 2 we'll cover when it makes sense to employ default values (and when it doesn't).

Navicat Blogs
Feed Entries
Blog Archives
Share