Devart Forums

This is the code but everything is working fine now. Thanks for your help with this.

using (DataModel1Entities db = new DataModel1Entities())
{
Multimaster mmparent = new Multimaster
{
Id = 3,
Value = "inserted"
};

Multimaster mmchild1 = new Multimaster
{
Id = 4,
Value = "inserted"
};

Multimaster mmchild2 = new Multimaster
{
Id = 5,
Value = "inserted"
};

Multidetail md1 = new Multidetail
{
Id = 3,
Multimaster = mmchild1,
Multimaster1 = mmparent,
Value = "inserted"
};
Multidetail md2 = new Multidetail
{
Id = 4,
Multimaster = mmchild2,
Multimaster1 = mmparent,
Value = "inserted"
};
db.AddToMultimasters(mmparent);
db.SaveChanges();
}
}

I would have to create a sample, because my view is tied to my application tables. But it seem like you was able to reproduce the problem yourself. The view that is composed of joining two other views set all fields in the returning view to primarily keys.

It seem to be working better in some cases, but doesn't work right in other cases. It set all the fields to primarily keys when you have a view that uses over views inside of it.

Thanks,

Charlie J.

Ok. I will do that and let you know by the end of this week.

Thanks,

Charlie J.

Does this include all fixes that was put into dotConnect for Postgres 4.95.190?

Great Thanks. I am able to work around it by editing all my views. It is alot of manual work.

Great Thanks. I was just making sure.

I am using dotConnect for Postgres 4.95.180.0 and not dotConnect for Oracle. My try it with dotConnect for Postgres 4.95.180.0.

Thanks,

Charlie J.

Is Item #1 still not support. Are edml models and RIA Services supported in dotConnect for Postgres 4.95.180.0?

Posted: Mon 29 Mar 2010 13:39 Post subject:

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

1. There is currently no support for .edml models and RIA Services.

I was having a problem setting it the model as well, because the Store had it as non-nullable and and changing the Model gives a fragmented mapping error because we are mapping nullable field to a non-nullable store.

I don't have an actual script for the tables and view I can send you, but just create some tables with non-nullable and nullable fields and use it in the view. The ADO.NET Entity will infer them correctly in the EDMX, but using the Devart Model will set every field as the Entity Key which have to be non-nullable in the EDML.

Thanks,

Charlie J.

The VS 2010 Devart Entity Model Template and Entity Developer (EDML) generate the CSDL and the SSDL incorrectly from my Database View. It set all the fields in the view to Entity Keys and make them non-nullable. My Database view join 3 tables that have primarly keys, and some some nullable fields in the table. When I generate an EDMX using the ADO.NET Entity Model and dotConnect for Progres Provider it seem to be generated correctly.

I am using dotConnect for Progres 4.95.180.0

Thanks,

Charlie J.

Great. Thanks. Procotol 3 Unprepared Execute=true; gives me the same performance as Procotol 2.

Charlie J.

Any Update on this issue?

Hey.

I am using the new dotConnect for Postgres 4.95.180.0 build.

[Devart]
We have fixed the problem with Unprepared Execute for connections created using DbProviderFactory. The fix will be available in the nearest build, which we plan to release next week.

This seem to have fixed the Unprepared Execute for connections created using DbProviderFactory when Protocol = Ver20. But the problem still exist for when Protocol=Ver30.

[Devart]
The performance problem is caused by the fact that by default Protocol 3 prepares commands before execution. When this preparation is disabled, the performance of Protocol 3 is approximately the same as the one of Protocol 2.

I need a fix for the performance problem when using DbProviderFactory and Protocol = Ver30.

Please run the sample test program you sent me to recreate the problem I am referring too on the latest dotConnect for Postgres version 4.95.180.0

Thanks,

Charlie J.
[/img]

Ok. I understand. Thanks. So the fixed you mention that will be ready this week, will fix the performance problem for using DBProviderFactory.

[Devart]
We have fixed the problem with Unprepared Execute for connections created using DbProviderFactory. The fix will be available in the nearest build, which we plan to release next week.