[ orm-Bugs-1641805 ] DDL Gen Error SQL Server Temporal: Date

[SourceForge.net <no...@so...>]

Bugs item #1641805, was opened at 2007-01-22 12:21
Message generated for change (Comment added) made by brian27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1641805&group_id=158881

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MattHuntington (matthuntington)
Assigned to: Nobody/Anonymous (nobody)
Summary: DDL Gen Error SQL Server Temporal: Date

Initial Comment:
The DDL created for Temporal: Date fields are being assigned the type of "INT". 

----------------------------------------------------------------------

Comment By: Brian Nalewajek (brian27)
Date: 2007-01-26 16:15

Message:
Logged In: YES 
user_id=1501525
Originator: NO

Hi Matt,

  There are a number of less than the best choices for data types in the
DDL generation scripts.  I thought that one of the team members referenced
this before, but I couldn't find it.  My belief is that the current release
was focused on stablity and performance issues with the core tool
functionality; and that the DDL scripts were not a high priority, but are
noted for later.

  I've found it best to take the DDL script that the custom tool
generation produces and do some editing on it before trying to run it. 
Actually, I make a copy of it in another folder I create in the project,
and use SQL Server 2005 Management Studio to open the file from that
folder.  When I open it in VS 2005 (my edition anyway), I get a plain text
editor; while SSMS gives me the color coded SQL editor, with parsing and
execution options.  After editing, I save it back to the project folder -
incase I need to try something else later.

  The other option is to run the DDL as is, and if it works, change the
data type for the columns in the DB.

  Either way will work, but the first is more self documenting. 
Obviously, better vendor specific script genereation would be best, but you
have option for now.

  BTW, I brought up the issue of doing the create schema in a transaction
in another item.  If you remove the GO directives until just before the SP
creation, the SCHEMA and TABLE creation will will work as a pass/fail
transaction, so if there's a problem, it's easier to clean up.  BRN.. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=809608&aid=1641805&group_id=158881