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
|
It appears as though even if I name tables and fields with upper-case letters, the entities get created with lower-case letters. If I create a table in SQL, with upper-case letters, and the entity names have the correct letter-case, the engine still thinks the entities are lower-case and toss an exception (table name or field name does not exists, due to names not matching). Looks like postgresql is case-sensitive, but Lightspeed is not. Is there a way to set this case-sensitivity in lightspeed?
VS2008 on vwindows vista32. Postgresql 8.3 on the same host. Third-party tools include pgAdmin III and MicroOLAP. Also, is there a way for lightspeed to create a postgresql datatype bigserial (bigint with a sequence for autoincrementing)?
There are also issues with data-type support for the time datatype in postgresql ( DateTime comes out as date in pg ). |
|
|
Just to confirm, this is referring to the designer rather than the runtime, is that correct? Entities are created with lower-case letters because that is the CLR naming convention. Normally I believe PostgreSQL is case-insensitive but I think you can force identifier names to be case-sensitive by quoting them -- is this your scenario? If so we may need to look at improving our inference to set the Table Name in this case. In the meantime, the workaround is to set the Table Name on each entity to the upper-case version of the name. No, LightSpeed will not currently create an autoincrement column. I've put this on the wishlist for v3 as we are doing quite a bit of work around database design improvements, but can't promise anything. Unfortunately for the DateTime model data type we currently have to just make an assumption about whether it maps to a date or time type -- the designer concerns itself primarily with CLR data types and does not yet have any mechanism to hint how these should be mapped to database data types. Again, this is something we will look at improving in v3. Thanks for drawing our attention to it. You should find that if you manually change the generated DATE column to a TIME column the designer will still accept that and not try to change it back for you. |
|