I see myself as a competent MySql-user, but now I have a basic problem with executing queries like SELECT * FROM User; and other trivial statements on my new MacBook Pro 15" with Retina Display and OS X 10.9.2.
I am trying to develop a web application using MySql 5.6 and PHP 5.5 on the server side, but almost every time I write and execute a statement I got the 1064 error code. I had attempted to do this in Coda 2 where I make my PHP scripts and MySql Workbench 6.0, but it did not work.
When I right-click on a table in Workbench and select Select Rows - Limit 1000 or let Wb generate an SQL-statement for me, everything is ok. Even if I copy the statement and modify some parts of the statement, the query gets executed and MySql does not give any error message.
I have checked my PHP document and that the database uses utf8. I did look for viable solutions for this problem in the web, but in vain.
Here is the code I tried to execute:
1 SELECT * FROM bo14g19.User LIMIT 0, 1000;
2 SELECT * FROM bo14g19.User;
3 SELECT * FROM bo14g19.User;
4 USE bo14g19
5 SELECT * FROM User
6 SELECT * FROM User
Line 1, 2, 4, and 6 is ok. Line 1 and 6 is generated by Workbench and line 2 is a direct copy from line 1 without the LIMIT. Line 3, 4, and 5 is manually typed in by hand.
Here you can find a screenshot from Workbench:
https://www.dropbox.com/s/4w6v9v3c0vainpx/mysql-workbench-execute-problems.jpg
Is this a known issue?
I found the problem! :-) My Keyboard language was set to "Sami", not "Norsk, bokmål"(Norwegian). So stupid and embarrassing, but the symbols and letters are just the same as in Norwegian, so I cant understand why it didmt work... The Norwegian and the Sami keyboard look exactly the same.
Related
I need to get transport data for my mobile app. Especially i would like to get Stop list with bus lines that stops on each bus stop.
I downloaded data from this link http://gtfs.ztp.krakow.pl/
Data for buses: GTFS_KRK_A.zip
Data for trams: GTFS_KRK_T.zip
Using PHP simple code I unzipped it, read .csv values from .txt files, add another column with changed varchar id to int id values using explode function, then save those files as .csv again to load it into transaction using mysql (that helps me introduce relations using indexes).
As I know the only possible way to get it is to connect 4 tables like stops with stop_times then, stop_times with trips and in the end trips with routes to get relation bus stop <--> route.
My SQL query is:
SELECT DISTINCT r.route_short_name
FROM google_transit_routes r
JOIN google_transit_trips t ON t.route_id_int = r.route_id_int
JOIN google_transit_stop_times st ON t.trip_id_int = st.trip_id_int
JOIN google_transit_stops s ON s.stop_id_int = st.stop_id_int
WHERE s.stop_name LIKE "Bieńczycka"
ORDER BY r.route_short_name ASC
Which returns:
103
125
127
129
664
When I check this bus stop online (which I believe is correct) it shows other lines that courses on this bus stop:
https://www.mapakrakow.pl/?ir=2&przystanek=Bie%C5%84czycka&lang=pl
103 and 644 are OK, but 125, 127, 129 shouldn't be in the return of my query.
Lines: 1, 5, 9, 14, 52, 64 are for trams which I didn't load yet - so it's good that query didn't return them.
Do you guys have any idea how to solve this problem?
I'm super aware of all the questions with pretty much this exact same name on here, but none of their solutions seemed to be the answer to my problems.
The query I'm using isn't very big, and I definitely have my packet size settings all configured correctly (never had a problem like this and some of my queries are properly large, much larger than the query in question).
I'm using prepared statements to pass some data to a fulltext search, and only when I seem to use it this way, I get this error. If I take the text out and paste it in as part of the query instead of preparing it, it works fine.
Also, in the MySQL log I get a huge error that starts like this
21:31:08 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
The query is this:
insert into`unpairedbillsuggestions`(`UnpairedBillSuggestionID`,
`ShippingBillID`,`InvoiceID`,`Score`,`DateTimeAdded`)
select`buuid`(),?,`InvoiceID`,`Score`,now()
from(select if(`invoices`.`InvoiceNumber`in(?,?,?),
5,0)`InvoiceNumberScore`,
if(`states`.`APO`=0,match(`shippingoptions`.`Company`,`shippingoptions`.`FullName`,`shippingoptions`.`AddressLine1`,
`shippingoptions`.`AddressLine2`)against(?),
match(`invoices`.`_APOCustomerAddress`)against(?))/
20`MatchScore`,
if(`invoices`.`_ShippingAccountNumber`=?,0.3,0)`ShippingAccountNumberScore`,-abs(datediff(date(`invoices`.`DateTimeShipped`),
ifnull(?,date(`invoices`.`DateTimeShipped`)-interval 14 day)))/7`DateScore`,
if(`invoices`.`_InvoiceTrackingNumberCount`=0,2,0)`InvoiceTrackingNumberCountScore`,`invoices`.`InvoiceID`,
`invoices`.`InvoiceNumber`,`invoices`.`DateTimeShipped`,`shippingoptions`.`FullName`,
`shippingoptions`.`Company`,`shippingoptions`.`AddressLine1`,`shippingoptions`.`AddressLine2`,
`shippingoptions`.`City`,`states`.`StateCode`,`countries`.`CountryCode3`,`shippingoptions`.`Zip`,
`invoices`.`_Total`,`invoices`.`_ShippingAccountNumber`,`companies`.`Name` `CompanyName`,`factories`.`Name` `Factory`,
`networks`.`Icon`,(select`InvoiceNumberScore`+`InvoiceTrackingNumberCountScore`+
`ShippingAccountNumberScore`+`MatchScore`+`DateScore`)`Score`
from`invoices`
left join`invoiceshippingoptions`using(`InvoiceID`)
left join`shippingoptions`
on`shippingoptions`.`ShippingOptionID`=`invoiceshippingoptions`.`ShippingOptionID`
left join`countries`on`countries`.`CountryID`=`shippingoptions`.`CountryID`
left join`states`on`states`.`StateID`=`shippingoptions`.`StateID`
join`companies`on`companies`.`CompanyID`=`invoices`.`CompanyID`
join`networks`on`networks`.`NetworkID`=`companies`.`NetworkID`
join`factories`on`factories`.`FactoryID`=`invoices`.`FactoryID`
where`invoices`.`InvoiceStatusID`<>'c9be156b-ffca-11e4-888d-3417ebdfde80'
having`Score`>0
order by`Score`desc
limit 5)`a`;
With the parameters being (all passed as strings):
'0a1c6452-4ec2-11e6-b570-12c139c58877'
'123456'
'789456123456'
''
'SOME COMPANY - SOME DUDE 117 W MASTER CHIEF LN, ORLANDO, FL 32816 USA'
'SOME COMPANY - SOME DUDE 117 W MASTER CHIEF LN, ORLANDO, FL 32816 USA'
'456789123'
'2016-04-27'
SELECT avg(costPrice) as avgCP from table1 where active=1;
This is the sql command to calculate average a column. This is giving the correct answer when I run the command using SQL in phpmyadmin.
But when I run this via PHP it returns wrong answer. Even when there are 2 rows with one active as 0 and one active as 1. It gives me average of both. why so?
I've been working on a project using the LAMP server that requires frequent read of the MS-ACCESS database, stored in *.mdb file. The database has one table and about 40.000 rows in it.
I've installed mdb-tools and configured unixODBC to use it. First impression was positive:
SELECT * FROM [Table]
Worked fine, however returned a huge structure, that overflew my buffer and the tail of data was truncated.
SELECT [col1], [col2], [col3] FROM [Table]
Worked fine as well, but the amount of data was still on the edge of usability (barely didn't exceed the buffer). So I've tried to limit result with the WHERE statement, but neither
SELECT * FROM [Table] WHERE [col1]=X
nor
SELECT * FROM [Table] WHERE [col2] LIKE 'xxx'
nor
SELECT [col1], [col2], [col3] FROM [Table] WHERE [col1]=X
nor
SELECT [col1], [col2], [col3] FROM [Table] WHERE [col2] LIKE 'xxx'
isn't working. They just return empty structure.
But if the condition is all-matching - it works:
SELECT * FROM [Table] WHERE [col2] LIKE '%'
returned that huge bulk of data
I know that mdb-tools is quite an ancient solution, that provides read-only access - but that's ok for me. I just want it to work.
I've tried both versions - from sourceforge and from github.
If col1 is a text column then use ... WHERE [col1] = 'some text' (note the use of quotes) for an exact match.
... WHERE [col1] LIKE 'xxx' is equivalent to ... WHERE [col1] = 'xxx'.
When using LIKE the wildcard character % matches zero or more characters, and _ matches one character, so
... WHERE [col1] LIKE 'To%'
should match "Toronto", "Tokyo", "Toledo", etc. ...
Edit
The man page for the mdb-sql command of MDB Tools does claim to support LIKE, so I put together a test .mdb file with a table named [Clients] that contained
ID LastName FirstName Email
-- ---------- -------------- ------------------
1 Thompson Gord gord#example.com
2 Loblaw Bob bob#example.com
3 Kingsley Hank hank#example.com
4 Thompson Hunter S. hunter#example.com
I did sudo apt-get install mdbtools on my test server (Ubuntu 12.04.02), uploaded the .mdb file and did the following
gord#pingu:~$ mdb-sql -p ~/ubuTest2003.mdb
1 => SELECT ID, LastName FROM Clients
2 => go
ID LastName
1 Thompson
2 Loblaw
3 Kingsley
4 Thompson
4 Rows retrieved
1 => SELECT ID, LastName FROM Clients WHERE LastName LIKE 'Thomp%'
2 => go
ID LastName
1 Thompson
4 Thompson
2 Rows retrieved
If you are having difficulty with WHERE clauses I would suggest running a similar test (with a small sample dataset) on your system using mdb-sql to see if WHERE clauses work in that context. If they don't work, then your MDB Tools is broken. If they do work, then we'll need to investigate further.
Edit
I spent some time trying to recreate this issue in PHP on my Ubuntu 12.04 test server. I was unable to do so, only because I was unable to get the odbc_ functions in PHP to work with mdbtools at all. I could establish a "valid" connection (no errors) and I could "execute" a query (again, no errors), but I could not get any query to actually return results, not even SELECT * FROM Clients.
In searching for assistance with my problem I happened upon the Stack Overflow article here, which further discouraged me from pursuing the matter further.
Instead, since this is apparently an active Access database hosted on a Windows machine, I personally would opt for using ODBTP. It is a free (GPL) TCP/IP protocol that allows you to pass queries to a Windows machine, which then submits the query via its ODBC driver and passes the results back to you.
It does require that a service be installed and run on the Windows machine, and the PHP client component must be compiled on Linux boxes, but if those requirements aren't too daunting then it is a pretty robust solution to this type of problem. (I have used it a few times in the past.)
And while it is true that ODBTP hasn't been updated for several years, it still works: I tested it just now with my LAMP server running the following PHP script to query an .mdb file residing on my older Vista notebook:
<?php
echo '<html><body><pre>';
echo "ODBTP test:\n";
$con = odbtp_connect('192.168.1.254',
'DRIVER={Microsoft Access Driver (*.mdb)};DBQ=c:\\__tmp\\ubuTest.mdb;UID=admin;PWD=;');
if (!$con) die('_connect error: ' . odbtp_get_error($con));
$rst = odbtp_query("SELECT * FROM Clients WHERE LastName LIKE 'Thomp%'");
if (!$rst) die('_query error: ' . odbtp_get_error($con));
while ($row = odbtp_fetch_assoc($rst)) {
echo $row['ID'] . ': ' . $row['LastName'] . "\n";
}
echo '</pre></body></html>';
The results as displayed in my browser window are
ODBTP test:
1: Thompson
4: Thompson
It's been a while...
mdb-tools is CRAP.
We have ended up by writing out own Windows service listening to SQL queries on a port given and proxing them to Access by an ADO connection.
So if only you have such opportunity, I recommend you not to use dead mdb-tools.
I have a sneaky suspicion that your WHERE col data contains some special characters like single quotes or double quotes OR there is some issues with PrimaryKey.
I'm using MDBTools and I successfully select cols from tables with wildcards, BUT when i try to select from a certain col that has some double quotes in the data, i get ZERO results. When I run php blah.php on that particular col, I get the error
CRITICAL: can't find column with internal id ### in index PrimaryKey
Found that in the code on line 309, but still not past it...
https://github.com/brianb/mdbtools/blob/master/src/libmdb/index.c
I have a webapp that lets you run querys from a DB using a simple textarea in a form. I have one problem:
I need to check the query memory consumption before it runs (so it won't crash my server).
Is there a way using PHP or MySQL to do that?
For example, i have 3 tables:
News (idNews,created,idMedio,state)
NewsAreaMain (idNewsAreaMain,idNews,idAreaMain)
AreaMain (idAreaMain)
and someone tried the following query that actually crashed the server:
SELECT DISTINCT News.*
FROM NewsAreaMain, News
WHERE
(
(
NewsAreaMain.idNews=News.idNews
AND News.idNews IN
(
SELECT DISTINCT News.idNews
FROM News, NewsAreaMain
WHERE NewsAreaMain.idNews=News.idNews
AND NewsAreaMain.idAreaMain="1"
)
)
AND idMedio="5"
OR ( idMedio="6" )
)
AND News.state=1
ORDER BY created DESC
LIMIT 0, 20;
Not that I know of. If there were one, I'm sure all the shared hosting sites out there would use it and block queries that are too intensive rather than using such a dirty method as killing queries that run too long.
That would probably be your only option. Have a process that periodically checked the first entry in SHOW PROCESSLIST, and if "Time" is above a certain value (it's in seconds, so 10 would probably be an ok, if tight, value. Anything above 60 is asking for trouble), kill it with KILL QUERY ##### (using the relevant ID number returned as part of SHOW PROCESSLIST).
No mysql query should crash the server. Mysql is quite good with that.
It seems it's not a query but some your code actually crashes the server.
If you care to provide more details on "crashing server", I am sure there will be a solution.