Detect reserved words (database and dialect dependant)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. For Oracle, add a migration which creates a table with a column that 
has the name "Start" (Start is a reserved word on Oracle)

What is the expected output? What do you see instead?
One gets the cryptic error message ORA-00904: invalid ID.

What version of the product are you using?
0.8.0

On what operating system?
Windows XP

With what .NET implementation/version?
VS2008 with .NET 3.5

What database and version are you seeing this issue on?
Oracle 10.2

Please provide any additional information below.
The fact that this message is cryptic is due to the Oracle driver. 
Migrator.NET could warn that the column name used is a reserved word (on a 
specific dialect of the selected provider).
When you intend to target multiple databases, it would be a very nice 
feature that one could check on the use of reserved words without actually 
having to create the tables and/or columns on the database server.

Original issue reported on code.google.com by paul.dhe...@gmail.com on 26 May 2009 at 2:09

[GoogleCodeExporter]

I have this issue with table names. If I quote the table name in the migration 
(e.g., 
"[User]") then it always assumes it doesn't exist (checking if the table exists 
before 
creating it). If I don't quote the table name, Migrator.NET will detect if the 
table 
exists and skip the migration, but if it does run the migration, the generated 
SQL is 
invalid.

Original comment by tgmayfi...@gmail.com on 27 May 2009 at 6:50

[GoogleCodeExporter]

Same problem.

I don't understand why we need logic to determine if a column-name/table-name 
needs to be quoted in the first place?

Just quote them all.

Original comment by rasmus.m...@gmail.com on 28 Jul 2010 at 5:12

[GoogleCodeExporter]

What are you doing about this? Have you just given up on this project and moved 
on or hacked up the source to work around this? There seems to be a lot of 
rough edges and a relatively old release date.

Original comment by cymen...@gmail.com on 6 Jan 2011 at 5:47

[GoogleCodeExporter]

From what I understand, a couple guys (not the original maintainer) did wade 
into the Migrator.NET source to get things cleaned up, fixed, and reorganized.  
But they ended up doing a complete rewrite and naming it FluentMigrator.  You 
can hear the full history on a Herding Code episode: 
http://herdingcode.com/?p=233

What I've done to bypass most of the trouble caused by keywords was to create a 
custom dialect (in my case, derived from SqlServerDialect) that overrides 
ColumnNameNeedsQuote and TableNameNeedsQuote so they both give "true".

Original comment by tgmayfi...@gmail.com on 6 Jan 2011 at 4:56

[GoogleCodeExporter]

I'll go check that out. Thanks!

Original comment by cymen...@gmail.com on 6 Jan 2011 at 5:27