Devart Forums

Thank you for the report, we have reproduced the issue. We will analyze the problem and inform you about the results as soon as possible.

Could you please describe the issue in more details? For example, please send us the model you are working with or the table definitions, so that we are able to analyze the situation in more details. At the moment, we couldn't reproduce the problem in our environment.

Setting the DeleteOnNull option to true is the correct suggestion. The problem is that the mapping is generated with DeleteOnNull enabled for both 'parent' and 'child' sides (while it should be set to true at the 'child' side only).

At the moment, you can either disable DeleteOnNull at the 'parent' side manually, or ignore the warning.

Thank you for the report, we have reproduced the problem with the exception being thrown. We will inform you when it is fixed.

At the moment, you can fix the mapping generated for the model manually. To do so, please find the mapping for the navigation property of the 'parent' entity (for example, it may look like '[Devart.Data.Linq.Mapping.Association(Name="Parent_Child"...' for the attribute mapping), and set 'DeleteOnNull' to false for it.

As for the warning, it is the expected behaviour. If, for example, the ObjectOne property is set to null in a 'main' object, the foreign key in the 'dependent' object should be set to null as well. Since the foreign key is not nullable (and, moreover, it is the primary key in this particular situation), this will lead to an error.

Could you please specify sample queries with which such problems occur and the tables being queried? If you are getting some other exceptions with different stack traces, please specify their messages and stack traces too.

As for resetting the LinqConnect parameters, the DataProvider instance is re-created each time you create a new DataContext object. The static components being shared among different instances of DataContext are:
1) The compiled query cache:
http://www.devart.com/linqconnect/docs/ ... eries.html
you can try disabling it by removing the following line in the code generated for your DataContext type: 2) The mapping source (this can be the problem's reason only if you are using the attribute mapping for your DataContext). If you do use the attribute mapping, the mapping source is created once and saved in a static field of [YourDataContext] type. Here is the corresponding generated code: You can, e.g., modify the code so that a static method that returns a new AttributeMappingSource object is used instead of this field.

We've recently performed substantial refactoring of the LinqConnect runtime. In particular, these changes have fixed the issue discussed in this thread. Please try using the LinqConnect 4.0.5 Beta build, and tell us if this helps. The Beta trial can be downloaded from
http://www.devart.com/linqconnect/download.html

Or you can wait for the LinqConnect 4 release, which we plan to publish in about two weeks.

We couldn't reproduce the issue in our environment. According to the stack trace, the problem occurs when trying to enlist the context connection to the distributed transaction. E.g., this may happen if you create a TransactionScope instance before using the context.

In either case, you can avoid such situations by changing the default connection behaviour (by default, a connection is always enlisted in the current distributed transaction). To do so, please set the 'Enlist' connection string parameter to false. Please tell us if this helps.

We have fixed the performance issue. The fix will be available in the nearest build, which we plan to release next week.

Could you please describe the scenario in more details? For example, do you explicitly open local and/or distributed transactions when retrieving data from the data context?

If possible, please send us a small sample with which the issue can be reproduced, so that we are able to analyze it in more details.

We will send you a sample project, please check that it is not blocked by your mail filter.

Generally, the following steps should be performed to run an application that uses LinqConnect under Mono:
1) Create a licenses.licx file and add the following entry to it: (this is actually done automatically if you are using Visual Studio to develop your application);
2) If you are going to use LinqConnect in an assembly that in turn is used by other applications, create the licenses.config file and specify the latter applications there. Place licenses.config next to licenses.licx.
3) Generate the license resource:
- find the license compiler (lc.exe) at the machine (with Windows) where LinqConnect is installed;
- run the compiler with the following command line: (the target should be just the application name, without the path to it);
- get the generated file ('MyApplication.exe.licenses') and add it to your project as an embedded resource.

As the license resource is available in the project, it should be possible to compile and run the application under machines where LinqConnect is not installed and, in particular, under Mono.

If the problem persists, you can send us your test project, so that we are able to analyze the licensing issue in details.

JIC: the assemblies from the Professional edition of LinqConnect need no technical licensing.

Sorry for the delay. The license resource should be compiled via the Windows license generator. The proper way of doing this is described, e.g., in
http://www.devart.com/dotconnect/sqlite ... ml#compile

If you are using the LinqConnect trial, it is necessary to add the following entry to the licenses.licx file before compiling the license: Please tell us if this helps.

Could you please specify the ORM (e.g., LinqConnect or Entity Framework) you are working with?

For example, this issue may occur if you are trying to create an Entity Framework object context, since the EntityConnection connection string format differs from the format of provider's connection string. For the detailed information about creating a proper EntityConnection connection string, please refer to the following topics:
http://msdn.microsoft.com/en-us/library/cc716756.aspx
http://msdn.microsoft.com/en-us/library/bb738533.aspx

We have released the new 3.2.57 version of LinqConnect, which includes the fix for this issue. The new build can be downloaded from
http://www.devart.com/linqconnect/download.html
(the trial and free versions) or from Registered Users' Area (for users with active subscription only).

For more information about the fixes and improvements available in the new version, please refer to
http://www.devart.com/forums/viewtopic.php?t=23638

We've released the new 3.2.57 build of LinqConnect, which supports Visual Studio 11 Beta. The new build can be downloaded from
http://www.devart.com/linqconnect/download.html
(the trial and free versions) or from Registered Users' Area (for users with active subscription only).

For more information about the fixes and improvements available in the new version, please refer to
http://www.devart.com/forums/viewtopic.php?t=23638

We have fixed the problem with DataContext objects not being garbage-collected. The fix will be available in the nearest build, which we plan to release in about a week.

We will inform you when this build is available.