We are currently moving the DB to another Server but we got a problem.
Our Database is quite big and when we want to Import it to our new MariaDB Server with
PhpMyAdmin. We got an Error Code and don´t know how to solve it.
Sorry that the Outcome is German, but it basically says that the key is too long The maximum key length is 767.
MariaDB Version: MariaDB-10.1.48Server Version: Ubuntu 18.04
Server Version: Ubuntu 18.04
If anyone could help with this Problem we would really appreciate an answer!
Example:
CREATE TABLE IF NOT EXISTS `accounts` (
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`owner` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`money` int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Outcome:
CREATE TABLE IF NOT EXISTS `accounts` (
`name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
`owner` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`money` int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
MySQL meldet: Dokumentation
#1071 - Schlüssel ist zu lang. Die maximale Schlüssellänge beträgt 767
As far as I know, you are defining name VARCHAR(255) COLLATE utf8mb4_unicode_ci NOT NULL and setting it as Primary Key. It is embedded in utf8mb4_unicode_ciyou have to divide the max index prefix length of 767 bytes (or 3072 bytes) by 4 resulting in 191.
Either you use VARCHAR(191) or not use it as your primary key
use
SET GLOBAL innodb_default_row_format='dynamic';
in your script or modify this parameter in my.ini
innodb-default-row-format = dynamic
with this change you can create index over columns up to 3072 bytes.
Related
I want all my tables, columns and references in the PDM to be generated as lower case values in the SQL scripts.
Tools > Model Options > Naming convention has been set to lower case for all the objects, but for some reason the primary key constraint name is defaulting to uppercase.
Is there a section of the menu that specifically sets the primary key that I am missing?
The Table Preview tab indicates all except the keys are being lower cased
I don't know what menu option I am missing I've tried all related to the model settings.
Example:
create table mtm_orders2customers (
objid SERIAL not null,
entry_date DATE null,
order_id INT4 null,
customer_id INT4 null,
payment_status VARCHAR(1000) null,
order_status VARCHAR(500) null,
order_total DECIMAL(12,2) null,
tax_due DECIMAL(12,2) null,
shipping_fee DECIMAL(12,2) null,
constraint PK_MTM_ORDERS2CUSTOMERS primary key (objid)
);
I tried with an Oracle Physical Model.
Looking in the DBMS, under ORACLE Version 18c::Script\Objects\PKey\ConstName, I see PK_%.U27:TABLE%.
If I change it to pk_%TABLE%, I'm closer to a lowercase primary key constraint name.
Same with ORACLE Version 18c::Script\Objects\Key\ConstName.
So, I got rid of wp_options db table by accident and I am trying to recreate or get the table back.
Is there a way of doing it without reset the whole wp db?
Thanks!
You can't restore it, unless you have a backup of it. Check with the service provider in case they have automated backup copy. Otherwise, Just try re-creating the table with the following queries. and activate the plugins again.
CREATE TABLE `wp_options` (
`option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`option_name` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
`option_value` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
`autoload` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'yes',
PRIMARY KEY (`option_id`),
UNIQUE KEY `option_name` (`option_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
Put your site url and run the following queries
INSERT INTO wp_options VALUES ('1', 'siteurl', 'YOUR_SITE_URL', 'yes');
INSERT INTO wp_options VALUES ('2', 'home', 'YOUR_SITE_URL', 'yes');
Then reactivate all the plugins. If any issues, revert back
I am setting up a website with a script that creates several MySQL databases during installation, and from time to time I have to reinstall the script several times because of changes I've made. During the re-installation, the install script wipes all the groups and categories in those groups. I have to manually input the groups and categories again.
This is two instances of the code and both wipe out databases that I have created and populated.
DROP TABLE IF EXISTS `categories`;
CREATE TABLE IF NOT EXISTS `categories` (
`id` int(10) unsigned NOT NULL auto_increment,
`category_name` varchar(255) character set utf8 NOT NULL,
`group_id` smallint(6) unsigned NOT NULL,
`description` text character set utf8 NOT NULL,
`page_title` varchar(255) character set utf8 NOT NULL,
`meta_keywords` text character set utf8 NOT NULL,
`meta_description` text character set utf8 NOT NULL,
`is_active` tinyint(4) NOT NULL default '1',
`created` int(11) NOT NULL,
`modified` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=13 ;
CREATE TABLE IF NOT EXISTS `categories` (
`id` int(10) unsigned NOT NULL auto_increment,
`category_name` varchar(255) character set utf8 NOT NULL,
`group_id` smallint(6) unsigned NOT NULL,
`description` text character set utf8 NOT NULL,
`page_title` varchar(255) character set utf8 NOT NULL,
`meta_keywords` text character set utf8 NOT NULL,
`meta_description` text character set utf8 NOT NULL,
`is_active` tinyint(4) NOT NULL default '1',
`created` int(11) NOT NULL,
`modified` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=13 ;
Of course it nukes it; you call
DROP TABLE IF EXISTS `categories`;
That's what DROP TABLE does: destroy the table.
DROP TABLE IF EXISTS categories;
was in the original script and after I discovered the problem I removed that line of code and included only the second example above. It still wipes out the category database even with that line of code removed.
Confusing?!
Thanks,
I've setup a simple bootstrap page to insert rows in my db, but I can't get the db to save in the right format/charset.
I want it to support multiple languages since I'm saving beer names from different countries, but even when I set the collation to a specific language on the affected rows and only submit letters from that charset, it still doesn't save the letters right.
Here's a table I exported from the db:
CREATE TABLE IF NOT EXISTS `Favorites` (
`fav_id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` varchar(55) CHARACTER SET utf8 COLLATE utf8_danish_ci NOT NULL,
`fk_beer_id` int(11) NOT NULL,
`fav_comment` varchar(255) CHARACTER SET utf8 COLLATE utf8_danish_ci DEFAULT NULL,
PRIMARY KEY (`fav_id`),
KEY `FK_FavBeer_Beer` (`fk_beer_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=7 ;
I get confused by the fact that (in PhpMyAdmin) I can set collations on both db, table and row.
Where and what collation is right for my db?
EDIT:
It may be because I'm using ajax to send the form:
I have the following settings:
contentType: "application/x-www-form-urlencoded; charset=UTF-8",
Solved it.
Used utf8_decode in the php file..
I have "Customer" table:
CREATE TABLE Customer
(
ID INTEGER NOT NULL DEFAULT 0,
Username CHAR(50) NOT NULL,
Password CHAR(100) NOT NULL,
LastName CHAR(20) NOT NULL,
PhoneNumber BIGINT NOT NULL,
MobileNumber BIGINT NOT NULL,
PRIMARY KEY (ID)
)
;
I used char for password type, is this right? And for mobile number I used bigint, is this right? If not what should I do ? And what is the SQL statement for it? Thanks.
As these fields will all be variable lengths you should definitely use VARCHAR instead of CHAR for 'Username', 'Password' & 'Lastname'. If you have limits on the lengths these then you can always limit the VARCHAR type to that limit.
As for 'PhoneNumber' & 'MobileNumber', you won't be performing any calculations with these values, so there's no reason not to store them as VARCHAR, not to mention that telephone number often contain a 0 as the first character which cannot be stored as an INT of any kind.
Something like:
CREATE TABLE `Customer` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`Username` varchar(255) NOT NULL DEFAULT '',
`Password` varchar(255) NOT NULL DEFAULT '',
`LastName` varchar(255) NOT NULL DEFAULT '',
`PhoneNumber` varchar(100) DEFAULT NULL,
`MobileNumber` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
All these questions matter on the requirements that you have...for example
You can use BIGINT for the MobileNumber if there are only going to be numbers in this field.
You will use VARCHAR if there can also be characters in it.
Both VARCHAR and CHAR have their own advantages and disadvantages.
Using VARCHAR gives you the freedom to have as many characters as you like in a single string, For example VARCHAR(30) can store upto 30 characters, and if there are less characters in it, then the rest memory is dumped automatically. You can also use VARCHAR(max) for this purpose, it will use all the characters passed and then dump the rest of the memory
CHAR(30) will also store 30 characters but it will not take care of the memory.
Memory may not be the issue in a smaller programs, but it can make significant effect if the program is huge.
For the password, use an array of bytes1 and store a one-way hash of the password. When the time comes to verify the password user has entered, hash it and compare it with the stored hash.
On top of that you should also use salting and (ideally) separate the whole authentication infrastructure to its own server beyond a firewall and a well-defined API.
Related answers:
How necessary is it to Encrypt database password field
store users and pass in single table or seperate table
1 RAW in Oracle, bytea in PostgreSQL, varbinary in MS SQL Server, BLOB in MySQL etc...