problem if vers extension are different of mysql version?
nawfer
(1) winXp
* Server: localhost via TCP/IP
* Versione MySQL: 5.1.37-community-log
Web server
* Apache/2.2.13 (Win32) PHP/5.2.10
* Versione MySQL client: 5.0.51a
* Estensioni PHP: mysql
phpmyadmin small notice that libraries different
(other dbs work; this is a db copyed from php4 mysql4 here)
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
but same db here
(2) centos
* Server: Localhost via UNIX socket
* Versione MySQL: 5.0.67-community
Web server
* Apache/2
* Versione MySQL client: 5.0.67
* Estensioni PHP: mysqli
work;
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
which cause this?
"Álvaro G. Vicario"
Saying "it doesn't work" can only lead to answers like "then fix it".
You say you are getting error messages and notices. Why not post them here?
P.D. mysql and mysqli are _different_ extensions
--
-- http://alvaro.es - �lvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programaci�n web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
nawfer
but a control with phpmyadmin said thata all the tables check are ok
this are the notices:
Problems with indexes of table `content_y`
Warning More of a key INDEX is created for column `id`
Problems with indexes of table `tablen`
Warning the keyes PRIMARY and INDEX not must be assigned both for column
`id`
Warning More of a key INDEX is created for column`table_s`
but under win xp and mysql5 there are is a table error:
check Error File key error for table : 'tablen';
check error Corrupt
query SQL:
SHOW KEYS FROM `tablen`
Msg MySQL: Documentation
#1034 - File key error for table : 'tablen'; try to repair (maked but not
change)
"Álvaro G. Vicario"
> this are 'only' notice in mysql4 (winxp) and mysql5 under centos
> but a control with phpmyadmin said thata all the tables check are ok
>
> this are the notices:
> Problems with indexes of table `content_y`
> Warning More of a key INDEX is created for column `id`
>
> Problems with indexes of table `tablen`
> Warning the keyes PRIMARY and INDEX not must be assigned both for column
> `id`
> Warning More of a key INDEX is created for column`table_s`
So you have a design problem in your database? It's not PHP's fault,
just fix your DB design and remove the duplicate indexes as advised.
> but under win xp and mysql5 there are is a table error:
> check Error File key error for table : 'tablen';
> check error Corrupt
>
> query SQL:
> SHOW KEYS FROM `tablen`
>
> Msg MySQL: Documentation
> #1034 - File key error for table : 'tablen'; try to repair (maked but not
> change)
http://dev.mysql.com/doc/refman/5.1/en/repair-table.html
nawfer
> El 29/12/2009 16:10, nawfer escribi�:
>> this are 'only' notice in mysql4 (winxp) and mysql5 under centos
>> but a control with phpmyadmin said thata all the tables check are ok
>>
>> this are the notices:
>> Problems with indexes of table `content_y`
>> Warning More of a key INDEX is created for column `id`
>>
>> Problems with indexes of table `tablen`
>> Warning the keyes PRIMARY and INDEX not must be assigned both for column
>> `id`
>> Warning More of a key INDEX is created for column`table_s`
>
> So you have a design problem in your database? It's not PHP's fault,
> just fix your DB design and remove the duplicate indexes as advised.
>
>
>> but under win xp and mysql5 there are is a table error:
>> check Error File key error for table : 'tablen';
>> check error Corrupt
>>
>> query SQL:
>> SHOW KEYS FROM `tablen`
>>
>> Msg MySQL: Documentation
>> #1034 - File key error for table : 'tablen'; try to repair (maked but not
>> change)
>
> http://dev.mysql.com/doc/refman/5.1/en/repair-table.html
I posted here not for to change db structure but for to
understand how solve this specific problems , see that under mysql5 work
good;
only in the setting where aren't egual the version of php extensions and
mysql server, have problems;
not want change db
"Álvaro G. Vicario"
It really helps to know this stuff from the beginning, it prevents us
from exploring paths that are already closed.
At PHP level you can ignore warnings in specific lines with the @ operator:
http://es2.php.net/manual/en/language.operators.errorcontrol.php
Or you can set a lower error reporting level:
http://es2.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
http://es2.php.net/manual/en/function.error-reporting.php
At database level, you can set an appropriate set of SQL Modes in order
to simulate legacy behaviours:
http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html
http://dev.mysql.com/doc/refman/5.1/en/dynindex-sqlmode.html
If neither of this is what you want, them I'm lost :(
Jerry Stuckle
As �lvaro said, you can change the warning levels. But that just fixes
the symptoms. You need to fix the problem - which is your database design.
Additionally, how did you copy database? Did you export/import, or copy
the files?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
nawfer
> the symptoms. You need to fix the problem - which is your database design.
> Additionally, how did you copy database? Did you export/import, or copy
> the files?
I create firs the db (olny name with phpmyadmin)
and after copied all files inner; think this is the better solutions;
one other solutions is to create an sql with phpmyadmin an recreate all
db's tables with an import; but I never haved success with this solution;
I never found a good tutorial for to make all the perfect settings for
clone exactly the original tables in a new db; there are too much settings;
but if you have a good link i can test.
Jerry Stuckle
>> As �lvaro said, you can change the warning levels. But that just fixes
>> the symptoms. You need to fix the problem - which is your database design.
>
>
>> Additionally, how did you copy database? Did you export/import, or copy
>> the files?
>
> I create firs the db (olny name with phpmyadmin)
> and after copied all files inner; think this is the better solutions;
>
Not a chance. Don't expect files from one version of MySQL to work on
another. You need to export/import your database.
>
> one other solutions is to create an sql with phpmyadmin an recreate all
> db's tables with an import; but I never haved success with this solution;
>
>
> I never found a good tutorial for to make all the perfect settings for
> clone exactly the original tables in a new db; there are too much settings;
> but if you have a good link i can test.
Nothing to do with PHP. You need to be asking on comp.databases.mysql.
nawfer
> nawfer wrote:
>>> As �lvaro said, you can change the warning levels. But that just fixes
>>> the symptoms. You need to fix the problem - which is your database design.
>>
>>
>>> Additionally, how did you copy database? Did you export/import, or copy
>>> the files?
>>
>> I create firs the db (olny name with phpmyadmin)
>> and after copied all files inner; think this is the better solutions;
>>
>
> Not a chance. Don't expect files from one version of MySQL to work on
> another.
really other db works; you would like said that not always but strange
that on other installation of mysql5 I haven't problem
>You need to export/import your database.
which solutions you use o prefer?
Scott Johnson
Nawfer Nawfer Nawfer
Unless I missed it in the thread but just reading the reply you
responded to, he never said 'not always'. He said do not expect it to work.
And why are you even arguing this issue. You have had several
knowledgeable people telling you the solution to your problem and you
are not willing to listen. Why are you even here if you don't believe
what you are being told. Go Google for an answer and you may find
someone to agree with you, but then you will still have your problem.
Sheesh!!!
Scotty
Michael Fesser
>> As �lvaro said, you can change the warning levels. But that just fixes
>> the symptoms. You need to fix the problem - which is your database design.
>
>
>> Additionally, how did you copy database? Did you export/import, or copy
>> the files?
>
>I create firs the db (olny name with phpmyadmin)
>and after copied all files inner; think this is the better solutions;
It's the worst of all. You shouldn't even touch the database files. They
are under the control of the DBMS and not meant for being manipulated
directly by a user. Copying them from one system to another might work
in some cases, but more likely it will corrupt your tables. Dependent on
the used storage engine you might even lose all your data. So forget
about these DB files and use the appropriate tools for import/export.
>one other solutions is to create an sql with phpmyadmin an recreate all
>db's tables with an import; but I never haved success with this solution;
Get familiar with the command line. On one machine you do a 'mysqldump'
to export all the tables you want (or even the entire database) into a
single file, including all the commands to create the table structures.
Typically all you need is something like this:
mysqldump -uUser -pPassword Database > dump.sql
Then on the other machine you simply import that file using the 'mysql'
command:
mysql -uUser -pPassword Database < dump.sql
That's how it's supposed to be and how it works reliably.
Micha
Jerry Stuckle
So, you haven't had a problem on other databases. You're very lucky.
nawfer
so I know, finally that isn't so;
only a clarification: inner same system there are problems also?
>>one other solutions is to create an sql with phpmyadmin an recreate all
>>db's tables with an import; but I never haved success with this solution;
>
> Get familiar with the command line. On one machine you do a 'mysqldump'
> to export all the tables you want (or even the entire database) into a
> single file, including all the commands to create the table structures.
> Typically all you need is something like this:
>
> mysqldump -uUser -pPassword Database > dump.sql
>
> Then on the other machine you simply import that file using the 'mysql'
> command:
>
> mysql -uUser -pPassword Database < dump.sql
>
> That's how it's supposed to be and how it works reliably.
but if I have file in localhost on win Xp how can to do this command for
export the tables or dbs on linux?
I resolved with using a last version of phpmyadmin and with export and
import sql but too many doubt; so create specific post for clarifications;
thanks for all suggestion
Michael Fesser
>I thinked that was how copy normal files between folders;
>so I know, finally that isn't so;
>only a clarification: inner same system there are problems also?
The problem is that you don't know for sure how exactly the DBMS stores
its informations and in which files. For example the default MyISAM
engine stores all the data in separate files, one for each table. But
the InnoDB engine uses just one big container file for all the data. And
other engines might even use completely different ways.
How all this stuff is handled and how the data is stored physically is
completely up to the DBMS. Think of it as a blackbox: You have a defined
API, which you can use to work with the DB. But how the data is actually
stored is an internal detail which you shouldn't mess with.
>> Get familiar with the command line. On one machine you do a 'mysqldump'
>> to export all the tables you want (or even the entire database) into a
>> single file, including all the commands to create the table structures.
>> Typically all you need is something like this:
>>
>> mysqldump -uUser -pPassword Database > dump.sql
>>
>> Then on the other machine you simply import that file using the 'mysql'
>> command:
>>
>> mysql -uUser -pPassword Database < dump.sql
>>
>> That's how it's supposed to be and how it works reliably.
>
>
>but if I have file in localhost on win Xp how can to do this command for
>export the tables or dbs on linux?
The commands are the same. Do a dump on one machine, copy the file to
the other one and import it there. It doesn't matter which platform
you're on. SQL is platform-independent, and the dump file contains
nothing else than pure SQL. It works on every system.
The only problems that may arise are incompatibilites between the MySQL
versions if they're too different. The manual has some chapters about
migrating to another version.
Micha