On Sun, Sep 19, 2010 at 01:38, sasha wrote:
> The biggest problem is views. You said that you don't include views into
> model because lack of information about keys.
Not *me*. It's Entity Framework that needs keys and designer that
doesn't include views (in case it cannot infer some key).
> I'v
> Might be worth reading
> http://blog.cincura.net/231978-seamless-support-for-boolean-and-guid-datatypes-in-firebird-and-entity-framework/
> before release; also in case you're not monitoring resolved bugs in
> tracker regularly.
I'ts very very nice, but we can't check it right now. Because of
p
> I'm still not convinced. Sure you can ensure the field is de-facto PK,
> but as it's more walking on thin ice than robust design I think you,
> as developer, should modify your model accordingly and keep it.
The biggest problem is views. You said that you don't include views into
model because
On Wed, Sep 15, 2010 at 11:51, Gareth wrote:
>
> If I use the option TransactionScope.Suppress in a nested transactionscope at
> present the provider seems to ignore this option and will not insert the
> first statement - an example.
> My understanding is that the first INSERT statement should be
On Mon, Mar 29, 2010 at 12:34, sasha wrote:
>>> 1) any column of table or view field (including not primary keys) with
>>> #PK_GEN# is a key field with autoincrement
>>
>> Though it's possible, why would you wanna mark field as PK if it's not
>> in database? This may (and will, you bet) strange er
