This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I'm using SQL Server 2008. I have a decimal entity property. When I do "Update Database" it creates the table with a column of type Decimal(24, 18). The column holds a money value so I need it to be more like Decimal(24, 5). The entity code gets generated with type "decimal" and there are no attributes around it to control the size of the column. So I figure it's just the default size SQL Server assigns when using a decimal type. The way to control the size in SQL Server is to specify it when writing the create table statement. But, thanks to LightSpeed, I'm not using SQL statements. Is there a way to control this through the LightSpeed designer? Or outside of the designer, or somehow? Or can such a feature be added easily? Just so I don't have to pre-create my whole DB just to control this one column. Using Update Database to create my schema is a very convenient feature. Thanks, Dominick
|
|
|
|
|
We don't currently provide any real support for fine-tuning the column definitions. LightSpeed 3 will provide increased control in this area and we'll aim to make sure your scenario is covered. Depending
on your usage patterns, you could edit the column after it's been
created. If you're progressively updating the database, the designer
should still recognise it as a decimal and not try to "fix" it for you
next time you update again. If this is your scenario but the designer keeps trying to "fix" your changes then let us know. However, this doesn't help if you are
fully recreating your database each time. If that is the scenario,
here is a possible workaround: do Update Database into a clean
dummy database, but turn on the Log SQL option. Then edit that generated SQL and run it against the clean real database.
To reduce the need for manual intervention, you could probably create a VS macro to automatically edit the scale/precision, save the edited text to a .sql file and invoke sqlcmd. (In fact if you did this you could inject statements to drop and recreate the database, so as to avoid the need to muck around with a dummy.) Note I have not tested this approach. |
|
|
|
