I have a DB called:
MY_XXXX and MY_YYYY.
When I go to the phpMyAdmin, it shows in the tree structure...like this:
So, my questions is, is the MySQL or the phpMyAdmin do this things for me...? Is this have some special meaning for that? Thank you.
This is phpMyAdmin making a (sort of reasonable-ish, a bit, actually largely un-warranted) assumption about a naming convention - it's nothing to do with MySQL.
If your looking for more information on such things - see the MySQL Schema Object Names documentation. (As you'll see - it defines no special meaning to the underscore other than stating that it's considered a valid character.)
THis means you have multiple databases starting with MY .
So rather then showing showing it in different headings as MY_1, MY_2 phpMyAdmin shows them as
MY_
1
2
etc.
Related
As many people already had, I have a problem in MySQL with the encoding of my data.
More specifically, the collation of the table seems to be utf8_general_ci. The data inserted is inserted well, but when a select is done, some characters get translated badly:
Marie-Thérèse becomes Marie-Thérèse.
Is it possible to do a select and translate these characters back to the original value, or is it impossible? It's harder to change the original table in my case, so I'd rather solve it in my select query.
When using phpmyadmin (or the like) and looking at those entries, are those entries okay?
update: if not, the inserts are probably flawed already, and the connection from the insertion script must be adapted.
If so, then it's not technically MySQL's fault but the software connecting to it. See for example: UTF-8 all the way through . You have to set some parameters on/after opening the connection.
btw: The collation should be irrelevant. http://dev.mysql.com/doc/refman/5.7/en/charset-general.html
The gist is: a collation tells the you, how you have to order/compare strings, which is mainly important for special characters like äöü in German or àéô in French/... because their local/regional collation say, ä is - for ordering purposes - exactly like a (for example), in another collation, ä could be distinctly after a or even after z.
In the end it seems like the problem was with running it all through a cronbjob.
We run a script through a cronjob that generates the insert statements. Apparently, when running the script manually, everything goes well, but when running the same script through a cronjob, the data got messed up. We solved that by this article:http://www.logikdev.com/2010/02/02/locale-settings-for-your-cron-job/
We had to add a variable LANG in the etc/environment file.
Say I have a table call ‘users’ with a column ‘order’ and I wish my application code to work across all the database systems out there.
Assume that it is impractical to change the database schema. Even if the schema was change, one of the main database engine will come up with yet another reserved word, so stopping the app working when a database engine is updated.
I would rather not have to process the SQL strings to convert them into the correct form for each database.
'How to find if a column name is a reserved keyword across various databases' partly overlaps with this question.
('Syntax error due to using a reserved word as a table or column name in MySQL' is the reference question for MySQL.
)
You have to test on everything you are going to support, so "all the database systems out there" is not in realty an option.
To be more realistic, you can decide which DBMS you want to support, and write a subset of SQL which they are all happy with, and test them with automated tests.
For example, you might consider:
MySQL
Postgres
MS SQL Server
Oracle
I believe these all support ANSI double-quotes for quoting names, so if you quote all names all the time then you have one less thing to worry about.
I'm wondering if a database name can start with a number e.g 143doors.
I found some answer here http://markmail.org/message/yw57rt3tweldtxet but I'm not quite sure since it's 1999.
Will there be disadvantages if I start with a number?
Within MySQL Workbench, you are going to have trouble querying if you do something like {db_name}.{table} and your db_name starts with a number.
The solution to this is the backtick mentioned in the accepted answer. An example is like:
select * from `2013e93`.blurb
where the db_name is 2013e93 and the table is blurb.
A quick test says, yes you can. Using spaces in database names will lead to trouble, though. You'll have to use `143 doors` (with the backtick) if you really want to do this.
I had an model with an "end" column (datetime format), only to discover that Heroku crashes and burns with illogical Active Record errors whenever I attempted to reference the column in a query. I spent two hours trying to debug the extremely simple query, after which point I renamed the column to "end_at" and all of my problems disappeared.
Has anybody else experienced this issue? I'm curious of the reasoning behind this and hope that we can help others avoid the same mistake. A similar question has been asked before, but a clear answer was not presented.
BEGIN and END are reserved words in Oracle and SQL Server, but not sure why MySQL doesn't consider them as such.
However that PGError would appear to indicate that the database engine itself (and not any Ruby-related runtime) has indeed rejected the query because of the "end".
Reserved words (and names containing spaces) can be used if quoted - perhaps Active Record didn't quote the identifiers in the SQL which was generated.
I would look at the log in MySQL (http://dev.mysql.com/doc/refman/5.5/en/query-log.html) and see the statements generated.
And since the PGError means PostGreSQL and you mentioned Heroku (PostgreSQL 8.3) - I think this is because END is indeed a reserved word in PostgreSQL: http://www.postgresql.org/docs/8.3/static/sql-keywords-appendix.html
http://www.petefreitag.com/tools/sql_reserved_words_checker/?word=end
PostgresQL (which Heroku uses) reserves END as a keyword, so it is giving you a syntax error because your syntax is incorrect.
There are two options for fixing it:
If Heroku is breaking because ActiveRecord is not quoting column names, you can rewrite every query that uses that model to explicitly quote the "end" column so PostgresQL doesn't blow up.
Whether or not ActiveRecord quotes that column name by default, renaming the column something more descriptive (end_time, end_date, etc) and also not a reserved word in both the language you are writing the app in as well as a reserved word in the SQL engine you are using.
Just wondered if there was a secret to do something like Database.Security.Users like AdventureWorks DB is setup. Seems no matter what I do to try to setup "Security.Users", I always get the dbo in front of it and have a hell of a time in C# accessing the info. Am I doing something wrong?
Are you trying to create an object called Security.Users with a dot? (as opposed to Users in the Security schema?) That's probably best avoided as you're seeing, but if you are then the best way to quote the name is probably in square brackets, i.e. [Security.Users].
dbo is the default database schema name. Unless you've configured a different default schema for your users etc. you can usually just ignore it, although it's still needed if you're referencing another database by name.
you first need to create a schema and make that schema the default schema for that user. Examples and more info can be found here: http://msdn.microsoft.com/en-us/library/ms190387.aspx
If you are using the Wizard to create this, you will always get it. Write the SQL statements and you should be fine.