If you’re getting an error that reads something like “unknown datatype for (columnname): “DATE”” in SQLite, it appears that you’re trying to define a column as a DATE type in a strict table.
SQLite doesn’t support the DATE type, however, this error should only occur on strict tables (i.e. a table defined as STRICT).
To fix this issue, either use a supported data type or make the table a regular (non-strict) table.
In most relational database management systems (RDBMSs) the PRIMARY KEY is used to define the unique row identifier for a table. But in SQLite, not all primary keys are handled the same way when it comes to indexing.
Depending on how the primary key is defined in a table, it may or may not show up in the list of indexes returned by the PRAGMA index_list() command. In particular, when the primary key is an INTEGER PRIMARY KEY, SQLite doesn’t explicitly create a separate index for it.
This article will explain why this happens and provide examples with different types of primary key definitions.
Deleting rows in a SQL database can sometimes be a nerve-racking experience. What if you’re deleting the wrong rows? Or what if the business later tells you they want their data back?
Fortunately SQL Server provides us with an easy way to essentially “back up” any rows affected by a DELETE operation to a table.
This article looks at using the OUTPUT ... INTO clause to save a copy of deleted rows to another table.
Perhaps you’re familiar with MySQL’s SERIAL type, which is not actually a data type, but a shortcut for BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE.
One restriction of SERIAL is that it forces us to use the BIGINT data type, which is fine if you think you’ll need the extra space. But what if you want the same attributes for a smaller integer type, like INT or MEDIUMINT for example?
Enter SERIAL DEFAULT VALUE.
If you’ve got an index in a SQLite database that you no longer need, you should probably get rid of it. Keeping unused indexes can be a drag on database performance, especially if your data is being regularly updated.
This article shows you how to delete an index in SQLite.
Prepared statements are a precompiled SQL queries that we can execute multiple times with different arguments. They are limited to the current session, so we can only create them and run them from within the same session.
Sometimes we might want to review how many prepared statements we’ve created. Or we might need to deallocate one, but we’ve forgotten its name.
No problem. We can use the pg_prepared_statements view to see all of our prepared statements.
In MySQL, a DEFAULT constraint is used to provide a default value for a column when no value is specified during an INSERT operation. This is particularly useful for ensuring that important columns have consistent, non-null values, even when omitted from inserts.
In this article, we’ll use MySQL to create a table with a couple of DEFAULT constraints, and we’ll also add a constraint to that table after it has been created.
If you’re getting an error that reads something like “Violation of PRIMARY KEY constraint ‘PK_CatId’. Cannot insert duplicate key in object ‘dbo.Cats’. The duplicate key value is (1)” in SQL Server, it’s because you’re trying to insert a duplicate value into a primary key column.
A primary key cannot contain duplicate values.
To fix this issue, you’ll need to change the value you’re trying to insert into the primary key column.
In database management systems (DBMSs) such as SQLite, indexes can be used to optimize the performance of queries, especially for larger datasets where querying can become time-consuming. An index allows the database to locate rows more quickly without scanning every row in a table.
This article explains how to create an index in SQLite, along with a simple example.