Hi 2E Users,
Are there any 2E Users out there that use the SQL Generators, and would care to share how they deal with the intricacies of Field Names in SQL when 2E generates using the Long Field Nanes?
For example, if I have a field named - 850 Quantity Qualifier
2E Generates a long field name - 850_QUANTITY_QUALIFIER
That's an invalid field name in SQL (DDL).
Do 2E Users in an SQL Model just know not to name fields which will translate to an invalid implementation name?
Thanks for any input.
Well, I use your SQL generator (from the Chicago conference, modified) and as the DBA I enforce a naming standard that excludes using numbers to start fields. I also discourage the use of special characters.
I suppose for those using a custom SQL generator I could modify the generator to create the column names with " " symbols around the names.....
Thanks for the reply. Good to hear you're enforcing a naming standard that will work with DDL. When you first moved to DDL, were you faced with any issues with old fields? I'm curious as to how prevalent badly named fields are. Maybe it's the model I work with, and it's rare.
If you place quotes around the column name, then I don't think that will work with SQL Data Access, because the generators would have to place Quotes around the column name as well. This would also be the case for any external SQL interface.
I did have a few issues. It was one of the reasons I went to the hard naming standard. For some files with fields, like "Some Value $" and Some Value %" I had to rename the fields to ensure unique column names.
As of right now, we don't use SQL data access (since it doesn't work with the custom SQL generator, but I'm working on that). So I don't really have a test case were I would have issues with " " names columns.
That's good input, thanks. It tells me that there was a reactive response rather than proactive, which is what I suspected. The 2E Model does no validation up front, and it's not until compile time that these issues are seen.
For users coming from DDS I can see this as being more of an issue. DDS has no issues with any naming for the 2E Fields. Users in a model using an SQL Implementation see this early, get used to it, and implement a DDL friendly naming standard. At least this is how it appears to me