I have a database table something like this...
CREATE TABLE IF NOT EXISTS `example` (
`id` varchar(78) COLLATE latin1_general_ci NOT NULL,
`username` varchar(78) COLLATE latin1_general_ci NOT NULL,
`password` varchar(78) COLLATE latin1_general_ci NOT NULL,
`reg_date` date NOT NULL,
`reg_time` time NOT NULL,
`permission` varchar(78) COLLATE latin1_general_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
Now I am performing a query from PHP is ...
INSERT INTO `example` (`id`, `username`, `password`, `reg_date`, `reg_time`, `permission`) VALUES ('j652hsL', 'example_user', 'secret', '', '', '');
This query is running Perfectly in my localhost with a warning of course but not problem in data insertion... Yes the reg_date, reg_time & permissions fields are holding 0000-00-00, 00:00:00& *Blank* respectively...But there is no problem with Insertion... Now this same Insertion Query is not running on a certain Web Server...
I have a web server and I tested it there it was running with no Error but When I shifted to different Web Server it wasn't running there... I think its a some kind of Server settings issue... But What possibly could stop it from inserting the Data?
Thanks all in advance.
Check if your local server and the web server uses different SQL MODE. Depending on how strict the mode is it handles zero-dates, default values and other things differently.
To get the current setting run show variables like 'sql_mode' on both servers.
Related
I have noticed when dealing with some names that are not of normal spelling ie standard alphabet UK/US are getting lost from my inserting of a record to what actually shows up in the database. I have done quiet a bit of reading regarding the Collation type, which is what I thought was causing the issue, but not sure if this is the case or I'm still doing it wrong as my problem is still persisting.
Below is an example of a record I am creating as well as my database structure, and as you can also see the last_name field has "ö", when I lookup the record I actually see the last_name "Körner"
CREATE TABLE `data` (
`id` bigint(20) NOT NULL,
`profile_id` int(11) NOT NULL,
`first_name` varchar(100) NOT NULL,
`last_name` varchar(100) NOT NULL,
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
ALTER TABLE `data`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `profile_id` (`profile_id`);
ALTER TABLE `data`
MODIFY `id` bigint(20) NOT NULL AUTO_INCREMENT;
INSERT IGNORE INTO data (profile_id, first_name, last_name) VALUES (1, 'Brent', 'Körner');
The field collation on the last_name is set to 'utf8_general_ci' which that I understand or should I say thought would sort this issue out.
This seems to be something I am doing wrong / missing with PHP, as when I execute the INSERT query within PhpMyAdmin it saves fine.
it seems the issue was down to PHP in the end, and i wasn't setting the charset.
For mysql
mysql_set_charset('utf8');
For mysqli
mysqli_set_charset('utf8');
ref https://akrabat.com/utf8-php-and-mysql/
Absolutely cannot get rid of these errors in phpmyadmin Version information: 4.2.11
$cfg['Servers'][$i]['users'] ... not OK [ Documentation ]
$cfg['Servers'][$i]['usergroups'] ... not OK [ Documentation ]
Configurable menus: Disabled
$cfg['Servers'][$i]['navigationhiding'] ... not OK [ Documentation ]
Hide/show navigation items: Disabled
$cfg['Servers'][$i]['savedsearches'] ... not OK [ Documentation ]
Saving Query-By-Example searches: Disabled
I have tried the following:
ran SQL
CREATE TABLE IF NOT EXISTS `pma_users` (
`username` varchar(64) NOT NULL,
`usergroup` varchar(64) NOT NULL,
PRIMARY KEY (`username`,`usergroup`)
)
COMMENT='Users and their assignments to user groups'
DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE TABLE IF NOT EXISTS `pma_usergroups` (
`usergroup` varchar(64) NOT NULL,
`tab` varchar(64) NOT NULL,
`allowed` enum('Y','N') NOT NULL DEFAULT 'N',
PRIMARY KEY (`usergroup`,`tab`,`allowed`)
)
COMMENT='User groups with configured menu items'
DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE TABLE IF NOT EXISTS `pma_navigationhiding` (
`username` varchar(64) NOT NULL,
`item_name` varchar(64) NOT NULL,
`item_type` varchar(64) NOT NULL,
`db_name` varchar(64) NOT NULL,
`table_name` varchar(64) NOT NULL,
PRIMARY KEY (`username`,`item_name`,`item_type`,`db_name`,`table_name`)
)
COMMENT='Hidden items of navigation tree'
DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Then updated my config.inc.php with
$cfg['Servers'][$i]['users'] = 'pma_users';
$cfg['Servers'][$i]['usergroups'] = 'pma_usergroups';
$cfg['Servers'][$i]['navigationhiding'] = 'pma_navigationhiding';
Then flushed table caches and restarted phpMyAdmin. The tables for pma_users and uaergroups have been created, but I still get the errors.
PLEASE HELP! This is causing serious issues with my drupal functionality.
Note, I have not yet set root or pma_user passwords.
Ultimately my solution to this problem was to move away from XAMPP local hosting. I moved my site files to remote server, and installed my database and imported my database to their phpyadmin without any issue. Site is now connecting and working beautifully. Spending countless hours following every post I could find and referring to the phpmyadmin documentation were to no avail as opposed to just abandoning ship and going with potentially a more novice user like myself. This worked for me because the remote hosting option was a viable. Unfortunately this answer is not helpful to those whom still need local hosting environment and are using XAMPP. I have the Aquia Dev Desktop that included XAMPP with great success in the past and maybe good option some.
I'm trying to do a fulltext search but it's not working in my web app. Here's an echo of the query and the error message:
SELECT name,id,city,state FROM campgrounds
WHERE MATCH(name, city, state) AGAINST('camp' IN BOOLEAN MODE)
Invalid query: The used table type doesn't support FULLTEXT indexes
I have converted the table to MyISAM and then dropped the index and recreated it.
delimiter $$
CREATE TABLE `campgrounds` (
`id` int(11) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`address` varchar(145) DEFAULT NULL,
`city` varchar(145) NOT NULL,
`state` varchar(5) NOT NULL,
`zip` int(11) NOT NULL,
PRIMARY KEY (`id`),
FULLTEXT KEY `name` (`name`,`city`,`state`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8$$
If I copy the above query into MySQL Workbench and run it, it works.
I'm a bonehead! MySQL workbench was attached to another server. I set it to my test server and the converted that table to MyISAM and all is good
Clear the cache of your App (Memcache or query cache). Because if it works with mysqlworkbech then it should also work with web app.
When using the query
select distinct(column_name) as column_name, data_type from information_schema.columns
where table_name='reg_add_ons' order by ordinal_position
I get an extra column on my dev server. On my local server everything works fine. This is the only table this happens on. I have tried dropping the table and adding it again with this statement
delimiter $$
CREATE TABLE `reg_add_ons` (
`add_on_id` int(10) NOT NULL AUTO_INCREMENT,
`eventcode` varchar(20) DEFAULT NULL,
`add_on_desc` varchar(250) DEFAULT NULL,
`add_on_price` decimal(10,2) DEFAULT NULL,
`add_on_detail` text,
`add_on_label` varchar(100) DEFAULT NULL,
`add_on_choices` varchar(200) DEFAULT NULL,
`image_name` varchar(100) DEFAULT NULL,
`internal_only` varchar(2) DEFAULT NULL,
`assign_code` text,
`reg_status` varchar(50) DEFAULT 'Active',
PRIMARY KEY (`add_on_id`)
) ENGINE=MyISAM AUTO_INCREMENT=89 DEFAULT CHARSET=latin1$$
I have a bit of the flu so this is not making sense to me right now.
Dev box is a Windows 7 machine running MySQL 5.6.10
Localhost is Windows 7 running MySQL 5.5.24
Production server is Linux MySQL 5.0.45
It is only this one table on this one machine (Dev) having problems. what is the field require_validation? Where does it come from?
Any insight is appreciated
I am running the following MySQL query:
select * from combinations where family_type='f597';
On a table that has about 90,000 lines. If I run the query via phpMyAdmin, it takes 0.3 seconds to run, but in my PHP page on the same host it consistently takes about 8 seconds.
To test the amount of time it takes in my page, I run it like this:
$secs = microtime(true);
$q = "select * from combinations where family_type='f597';";
$r = mysql_query($q);
$secs = round(microtime(true)-$secs, 3);
exit("$secs seconds");
The table structure is as follows:
CREATE TABLE `combinations` (
`part_no` char(7) collate latin1_general_ci NOT NULL,
`key_type` smallint(4) unsigned NOT NULL,
`family_type` char(5) collate latin1_general_ci NOT NULL,
`year_start` varchar(6) collate latin1_general_ci NOT NULL,
`year_end` varchar(6) collate latin1_general_ci NOT NULL,
`visual` varchar(31) collate latin1_general_ci NOT NULL ,
`info_veh_0` varchar(255) collate latin1_general_ci NOT NULL,
`info_veh_1` varchar(255) collate latin1_general_ci NOT NULL,
`info_veh_2` varchar(255) collate latin1_general_ci NOT NULL,
`key` mediumint(8) unsigned NOT NULL auto_increment,
PRIMARY KEY (`key`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=2349584 ;
Can anyone explain why my program runs the same query so much slower than phpMyAdmin?
[update 1] I tested the query outside of any other programming -- I created a simple test.php page that contained only the mysql connect info and the query in question. So a priori it's not some other aspect of the site programming that's causing the delay.
[update 2] The actual time that it takes to load the page is the same for phpMyAdmin and for my test page. The difference may be due to the way that phpMyAdmin calculates the query time.
In any case, if the query takes only 0.3 seconds to process, where does the rest of the delay come from?
This could be because phpMyAdmin adds a limit clause behind the screen due to the fact that it's paginating the results.
When you run your sql query you get all the records which suits you criteria. But if you don't show all all of them in your page get records how many you want to show at your web page. I mean page them.
If it is on a linux box, you can try to query the serveur using the tool "mysql" if you want to check.