AW: Decrypt MYSQL Password
Hi Ben, As far as I know the algorithm used for the decrypting is a one-way hash function, thus there is no way of decrypting it. You may consider to reset the password and mail the user the new one instead of mailing the old password. The second solution is to store the password a second time as clear-text at the user's property. Regards, Wolf -Originalnachricht- Von: Ben C. An: [EMAIL PROTECTED] Gesendet: 13.11.2002 08:27 Betreff: Decrypt MYSQL Password I am using the MySQL password() function for the my passwords on the user names. How do I decrypt the password in PHP to send it in an e-mail. I am making a forgot your password page and want to have the user enter their e-mail and have the password sent to them. Please help! -- The content of this email message and any attachments are confidential and may be legally privileged, intended solely for the addressee. If you are not the intended recipient, be advised that any use, dissemination, distribution, or copying of this e-mail is strictly prohibited. If you receive this message in error, please notify the sender immediately by reply email and destroy the message and its attachments. - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Bug at GRANT statement?
Hi, When one is doing a GRANT statement at the database level the database name is stored in mysql.db in lowercase letters only, regardless of the upper/lowercase characters used for the database name at the GRANT statement. Example: GRANT SELECT ON SYSMON.* TO theUser@% results in having stored the database name SYSMON as sysmon at mysql.db, column db. GRANT SELECT ON SysMon.* TO theUser@% will grant the privilege to the same database sysmon as the statement above. On a Unix plattform there can be two different databases SYSMON and SysMon! Furthermore, if one manually changes the database name back to the original name - SYSMON - at the column mentioned above and re-run the statement there is a second entry generated in mysql.db: the old one having SYSMON and the new one having sysmon as database name. As the database name is case-sensitive in Unix systems this is critical. I'm running on Win XP, and found this behavior in mysql-MAX NT versions 4.0.2 to 4.0.4. Is this a Bug or intended behaviour? Best regards, Wolf - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
AW: Bug at GRANT statement?
Veronica, That's maybe true, I'll check it. As it's the default setting on Windows and I've never changed it I guess it's on. If the flag lower_case_table_names is turned on, I would expect that SHOW DATABASES os SHOW TABLES is returning lowercase-only names as well? I do get back the exact database and table names as the files in the DATA directory are named, including full upper/lowercases, thus I do get back the name as originally specified when creating the database / table. The manual says (including LOOKUP queries): 8=== If lower_case_table_names is 1 MySQL will convert all table names to lowercase on storage and lookup. (From version 4.0.2, this option also applies to database names.) ===8 Thanks! Best regards, Wolf -Originalnachricht- Von: Victoria Reznichenko An: [EMAIL PROTECTED] Gesendet: 08.10.2002 12:44 Betreff: re: Bug at GRANT statement? Moestl, Tuesday, October 08, 2002, 10:42:09 AM, you wrote: MW When one is doing a GRANT statement at the database level the database name is stored in mysql.db in lowercase letters only, regardless of the upper/lowercase characters used for the database MW name at the GRANT statement. MW Example: MW GRANT SELECT ON SYSMON.* TO theUser@% MW results in having stored the database name SYSMON as sysmon at mysql.db, column db. MW GRANT SELECT ON SysMon.* TO theUser@% will grant the privilege to the same database sysmon as the statement above. On a Unix plattform there can be two different databases SYSMON and SysMon! MW Furthermore, if one manually changes the database name back to the original name - SYSMON - at the column mentioned above and re-run the statement there is a second entry generated in mysql.db: MW the old one having SYSMON and the new one having sysmon as database name. MW As the database name is case-sensitive in Unix systems this is critical. MW I'm running on Win XP, and found this behavior in mysql-MAX NT versions 4.0.2 to 4.0.4. MW Is this a Bug or intended behaviour? It's not a bug. Seems, you start MySQL server with lower_case_table_names=1. In this case all table/database names will be convert to lower case (SYSMON-sysmon, SySMon-sysmon): http://www.mysql.com/doc/en/Name_case_sensitivity.html -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Victoria Reznichenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net ___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
WG: Odd behaviour if you use incorrect case for table name
Hi Phobe,
As the MyIsam tablehandler stored the tables as files on the file system the OS
specific case sensitivety for file names comes into place here.
On a Unix system you have to use the correct cases for the table names, on a Win*
System the cases of the table names does not matter.
The same is true for datbase names as well.
Column names should not be case sensitive anyway.
I guess you're on some Unix platform?
I hope that helps!
Best Regards,
Wolf
-Ursprüngliche Nachricht-
Von: Phoebe Bright [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 26. September 2002 12:12
An: MySQL
Betreff: Odd behaviour if you use incorrect case for table name
I thought you might be interested in a bug that I traced to my having used
the wrong case for the table name. This had me baffled for a while because
the behaviour was not consistent, sometimes the error was duplicate key,
other times wrong column count
CORRECT BEHAVIOR =
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('BROWSP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO task VALUES ('BROWSP','2','Test software, hardware and
linkages')
RESULT: 1 Rows affected.
select * from task
| projectid | taskid | name |
| BROWSP| 1 |Maintain data code|
| BROWSP| 2 |Test software, hardware and linkages|
Number of Results: 2
What happens if you use Task instead of task in the second Insert
== APPEARED TO WORK ===
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('SUPP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO Task VALUES ('SUPP','2','Test software, hardware and linkages')
RESULT: 1 Rows affected.
SO TRIED IT WITH A SELECT AT THE END =
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('SUPP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO Task VALUES ('SUPP','2','Test software, hardware and linkages')
ERROR: Query failed (Duplicate entry 'SUPP-2' for key 1)
select * from task
| projectid | taskid | name |
| SUPP | 1 | Maintain data code |
Number of Results: 1
ANOTHER VARIATION ==
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('BROWSP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO Task VALUES ('BROWSP','2','Test software, hardware and
linkages')
ERROR: Query failed (Column count doesn't match value count at row 1)
=== SAME AGAIN WITH A SELECT
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('BROWSP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO Task VALUES ('BROWSP','2','Test software, hardware and
linkages')
RESULT: 1 Rows affected.
select * from task
| projectid | taskid | name |
| BROWSP| 1 | Maintain data code |
Number of Results: 1
=== WITHOUT THE SELECT
DROP TABLE IF EXISTS task
RESULT: 0 Rows affected.
CREATE TABLE task (
projectid varchar(8) NOT NULL default '',
taskid varchar(8) NOT NULL default '',
name varchar(60) NOT NULL default '',
PRIMARY KEY (projectid,taskid)
) TYPE=MyISAM
RESULT: 0 Rows affected.
INSERT INTO task VALUES ('BROWSP','1','Maintain data code')
RESULT: 1 Rows affected.
INSERT INTO Task VALUES ('BROWSP','2','Test software, hardware and
linkages')
ERROR: Query failed (Duplicate entry 'BROWSP-2' for key 1)
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try:
Case sensitivety behaviour
Hi, Is there a defined behaviour for handling the case-sensitivety for user- and hostnames? I did not find any information on this at the docs for the 4.0.3 MAX version which I'm using. For example, the following database connections are valid: root@localhost Root@localhost However, the following connection is resulting in an Connection failed: 1045 - Accss denied for user: ... error: ROOT@localhost ROot@localhost It looks like the host parameter is completely insensitive for cases, every combination of upper- and lowercase characters it taken. To get it even more confusing, the values for user and host at the SHOW GRANTS FOR [user]@[host] are BOTH FULLY case-sensitive. Only the exact values as beeing stored at the mysql system tables are taken. The following statements does return values: SHOW GRANTS FOR root@localhost The following statements will NOT return values: SHOW GRANTS for Root@localhost SHOW GRANTS for root@Localhost Personnaly I think the same case-sensitivety behaviour should be implemented in every aspect of the database functionallity. If connecting as Root@LOCalhOST works a SHOW GRANTS FOR Root@LOCalhOST should work as well. Best regards, Wolf - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Bug at Hostname parameter for SHOW GRANTS FOR ...?
Hi, If you have a host having the minus character '-' in the name the mysql command SHOW GRANTS FOR fails. Example: SHOW GRANTS FOR root@MY-COMUPTER results in the error message You have an error in your SQL syntax near '-COMPUTER' at line 1. It looks like the command processor stops the parsing for the hostname at the '-' character and tries to find an appropriate command sequence afterwards. Is this a Bug or expected behaviour? Best regards, Wolf - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
AW: Importing date data from text files
Hi Andrew,
DATE_FORMAT is the function you're looking for.
Check the documentation on it, chapter 6.3.4 Date and Time Functions.
DATE_FORMAT works like the following:
SELECT DATE_FORMAT('1997-10-04 22:23:00', '%W %M %Y');
BTW, SQL Server offers the CONVERT function for this purpose. No need to use some VB
script in order to convert strings into dates.
Best regards,
Wolf
Hi - I am relatively new to MySQL, previous experience is mainly Visual
FoxPro and MS SQL2000.
I have a client who supplies data in text files. In numerous of these
files and subsequent tables there are date fields.
In the UK we use the date format of dd/mm/. I understand that MySQL
only accepts data in -mm-dd, and as far as keeping the data in MySQL
I don't have a problem with that, but somehow I have to get the data
into MySQL tables from the text files.
In SQL Server, I can do this using some VB script in a DTS... is there
anything similar, or, does anyone have any other ideas?
Many thanks
Andrew
JM Data Services
8 Stanton Road
Wimbledon
LONDON
SW20 8RL
t: 020-8286 8545
f: 020-8944 8621
m: 07801-866043
e: [EMAIL PROTECTED]
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
AW: Table partitioning functionality
Hi Daniel, So what would be a good solution within MySQL to store large amounts of data if they have to go into a single table? InnoDB seems to be the right table type to use (especially as they support transactions as well) but you do not have controll over the used tablespace. They are just filled up one by one when inserting new data. I'm afraid doing table scans on table having a very high row count will kill performace. Even on a Oracle 9i I had alreay 50 minutes for a single full table scan on the table. Bye, Wolf -Ursprüngliche Nachricht- Von: Daniel Kiss [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 5. September 2002 13:07 An: Moestl, Wolfgang Betreff: Re: Table partitioning functionality Hi, No, I'm afraid. MyISAM tables cannot be cut in several pieces. But check ot the InnoDB table type, because they work very similar to Oracle. InnoDB uses tablespaces, and there can be many of them, maybe with autoextend functionality. I know it is not the same you would like, but maybe you can use this feature for your task. Bye, Daniel At 12:28 2002.09.05. +0200, you wrote: Hi, Does MySQL offering a similar functionality as Oracle does with table partitioning? Oracle can split a table into several pieces where the pieces are - usually - identified by a range of valus. For example, one may split a table holding data on a daily basis into monthly partitions. Oracle will store the data in the partition identified by month of the new inserted data. As the tablespace used by each partition can be specified this is very usefull to spread the disk IO to several harddisks. The main reason for partitioning a table is to make VERY large tables more performant. Oracle fetches only the partions needed by the SQL statement, this means a full table scan will only process partitions identified by the WHERE clause and not the full range of data. If MySQL does not offer this or a simmilar functionality, how does MySQL perform on very large tables (I'm talking here about 10 Gigs+ of data stored in a single fact table)? Best Regards, Wolfgang - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Table partitioning functionality
Hi, Does MySQL offering a similar functionality as Oracle does with table partitioning? Oracle can split a table into several pieces where the pieces are - usually - identified by a range of valus. For example, one may split a table holding data on a daily basis into monthly partitions. Oracle will store the data in the partition identified by month of the new inserted data. As the tablespace used by each partition can be specified this is very usefull to spread the disk IO to several harddisks. The main reason for partitioning a table is to make VERY large tables more performant. Oracle fetches only the partions needed by the SQL statement, this means a full table scan will only process partitions identified by the WHERE clause and not the full range of data. If MySQL does not offer this or a simmilar functionality, how does MySQL perform on very large tables (I'm talking here about 10 Gigs+ of data stored in a single fact table)? Best Regards, Wolfgang - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
