I have a simple problem.
I've created a WCF Data Service 5.6 in visual studio 2013, and in its *.svc.cs file, modified line
public class CustomdataService : DataService< /* TODO: put your data source class name here */ >
to connect my entities
public class CustomdataService : DataService< SchedulerEntities >
But when I want to see the service in browser it gives me following error
Request Error
The server encountered an error processing the request. See server logs for more details.
The entity framework is nothing but a single table...
The actual error can be different. In my case I got the same general error message when starting with AdventureWorks2012 database.
So the actual problem can be seen by appending an attribute to the service class as described at here:
[ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class WcfDataServiceAW : EntityFrameworkDataService<AdventureWorks2012Entities> { ... }
Hope it helps someone.
PS. My error is:
The exception message is 'The property 'SpatialLocation' on type 'Address' is of type 'Geography' which is not a supported primitive type.'.
It seems that Entity Framework 6 and WCF Data Services 5.6.0 need some provider to work together, read more on Using WCF Data Services 5.6.0 with Entity Framework 6+.
You can download the provider simply by using NuGet Package Console Manager:
Install-Package Microsoft.OData.EntityFrameworkProvider -Pre
Its version is alpha 2, so in future, search for final release. it worked for me however.
Final thing is, instead of using DataService<T>, you need to use EntityFrameworkDataService<T>. T is the name of your entities.
According to this post, you have to change inherited type of CustomdataService.
Replace the base type of your DataService. For EF 5 or below, your data service should inherit from DataService where T is a DbContext or ObjectContext. For EF 6 or greater, your data service should inherit from EntityFrameworkDataService where T is a DbContext. See What’s the difference between DataService and EntityFrameworkDataService below for more details.
go to edmx, in the diagram, remove all the tables until the only one you want is remain,
then should be okay, cannot have all the tables, this is what I found,
KT Wong
Related
The goal is to use persistence with a class that contains a geometry information and to store this information into an Oracle SDO_GEOMETRY field.
Tools used :
Apache Netbeans 12.4 with eclipseLink 2.1 driver
Payar Server 5.2021 for application deployment
The class calls a class transformer to transform JGeometry type to MDSYS_SDO_GEOMETRY expected by Oracle if I understand well. It looks like :
Adresse.java class with converter call: java class
My persistence file looks like : persistence.xml
I used "eclipselink.classloader" but it seems not to solve the problem.
When executing the appplication the server returns this error :
Exception Description: Predeployment of PersistenceUnit [com.spt_adressagenumerique_war_1.0-SNAPSHOTPU] failed.
Internal Exception: Exception [EclipseLink-7351] (Eclipse Persistence Services - 2.7.7.payara-p3): org.eclipse.persistence.exceptions.ValidationException
Exception Description:
The converter class [org.eclipse.persistence.platform.database.oracle.converters.JGeometryConverter] specified on the mapping attribute [position_gps] from the class [com.spt.database.Adresse]
was not found. Please ensure the converter class name is correct and exists with the persistence unit definition.
I finally found the following solution :
Use of eclipse IDE 2021-06
Use of hibernate instead of eclipseLink
Use of hibernate-spatial and indication of org.hibernate.spatial.dialect.oracle.OracleSpatial10gDialect in hibernate.cfg.xml
Creation of a geometry point Point G2D based on org.geolatte.geom
Mapping with the same type in the class definition.
With this solution no need to get sdoapi.jar from Oracle installation.
Thanks and may this solution helpful .
I am trying to use an Ice client in an OSGi context. Running the server and a minimal example client in a non-OSGi environment works fine. With the client in an OSGi environment I get the following exception:
com.zeroc.Ice.NoValueFactoryException
reason = "no value factory found and compact format prevents slicing (the sender should use the sliced format instead)"
type = "::MyModule::Knowledge::CMKnowledge"
However, I am not 100% sure, if the OSGi runtime makes a difference here. The Slice file looks like this:
module MyModule{
module Knowledge{
class KnowledgePart{
string value;
}
class FMKnowledge extends KnowledgePart{}
class CMKnowledge extends KnowledgePart{}
interface IKnowledge{
void sendKnowledge(KnowledgePart knowledge);
FMKnowledge getFMKnowledge();
CMKnowledge getCMKnowledge();
}
}
}
What does this exception mean in this context and how can I fix it? I already tried to set ["format:sliced"] instead of the implicitly used compact format.
The error mean that Ice run-time try to load MyModule.Knowledge.CMKnowledge class but it failed to do so. You must ensure that the class loader used by the application can load MyModule.Knowledge.CMKnowledgeclass.
See also https://doc.zeroc.com/ice/3.7/language-mappings/java-mapping/custom-class-loaders
I'm trying to delete an entity but the delete query is not generated and there's no error shown in the console :
#Override
#Transactional
public void removeClassObject(MyClassObject classObject) {
MyClassObject ip = entityManager.find(MyClassObject.class, classObject.getId());
entityManager.remove(ip);
}
Take notice : #Transactional is from springFramework package
EDIT :
All my configuration are ok, because I already have the merge and persist functions doing there job without any problem it's just the remove method which doesn't generate any sql query and does not remove the given entity.
EDIT 2 :
This is how I obtain my entityManager :
#PersistenceContext(type = PersistenceContextType.TRANSACTION)
protected EntityManager entityManager;
If you are using #Transactional annotation, you should consider using interface for your service, and not only implementation.
#Transactional will need a dynamic proxy to be created on your bean to apply the transactional logic, which can be created if your Service has an interface. Otherwise you would need to manage transaction on your own.
In answer I assume that you create entity manager with
#PersistanceContext annotation and your service has no interface.
For mor information : Spring transactions
EDIT:
Also make sure, that you have enabled transactions in your configuration. Look here for similar error but with wrong configuration LINK
I'm dipping my foot into WCF and am trying to make a simple test project that can both consume the service as a service and also directly instantiate it's classes and work with them.
I had an earlier working version where data passed was just primitive types. However, when I attempted to convert to using data contracts, I'm getting conflicts in whether it's referencing the proxy-declared version of the contract or the version from the project itself.
Question: Is it possible to do this and if so, how would I resolve the data contract references?
private void Test()
{
MyService fssDirect = new MyService(); // direct instantiation
MyServiceClient fssService = new MyServiceClient(); // Service proxy
ClientCredentialsContract Client = new ClientCredentialsContract();
ResponseDataContract Result = new ResponseDataContract();
if (CallAsService)
{
Result = fssService.Create(Client, Request);
}
else
{
Result = fssDirect.Create(Client, Request);
}
}
In the above, any reference to the RequestDataContract and ClientCredentialsContract types indicates
Warning: The type 'MyContracts.RequestDataContract' in 'C:...\Test\MyServiceProxy.cs' conflicts with the imported type 'MyContracts.RequestDataContract' in 'C:...\MyService\bin\Debug\Contracts.dll'. Using the type defined in 'C:...\Test\MyServiceProxy.cs'.
(Names changed and paths shortened to protect the innocent)
Thanks,
John
When you create the proxy for your service, try referencing the assembly which contains the data contracts (if using "Add Service Reference", go to the advanced options, select "reuse types in referenced assemblies"; if using svcutil, use the /r argument). This way the tool won't generate the data contracts and you won't have the conflicts.
I am working on WCF Data service which imported stored procedure, as below.
[WebGet]
public List<GetMTSearchResultTest_Result> GettMTSearchResultTest()
{
MediaMarketResearch_PRODEntities ent = new MediaMarketResearch_PRODEntities();
return ent.GetMTSearchResultTest().ToList();
}
when i consuming this in my client application it says error as "The closed type MMRClient.MMRServiceReference.GetMTSearchResultTest_Result does not have a corresponding element settable property."
I am getting this error while bind to the grid view as below.
DataServiceContext context = new DataServiceContext(new Uri("http://localhost:4131/MMRDataService.svc/"));
IEnumerable<GetMTSearchResultTest_Result> empResult = context.Execute<GetMTSearchResultTest_Result>(new Uri("http://localhost:4131/MMRDataService.svc/GettMTSearchResultTest"));
GridView1.DataSource = empResult;
GridView1.DataBind();
Note: I imported this stored proc as complex type.
Please advice me on this.
Regards,
Jaydeep
I think this link may help you (see the selected answer).
Essentially, what the solution may be is to create a partial class for GetMTSearchResultTest_Result and decorate it with a DataServiceKey attribute, providing a non-nullable column that acts as a primary key (although I don't think it has to be unique).
So your partial class would look something like:
[DataServiceKey("YourKeyColumnName")]
public partial class GetMTSearchResultTest_Result {
}
If you're just doing reads, I don't think you'll need any implementation.
Hopefully this works. Let me know if there are issues/questions and I'll update accordingly.
You can always make a new service reference to a non data service. That is to a normal WCF service. You can simply have a [ContractOperation] returning a list of the troubled "complex types" and that's it.
This way you would have two services the original data service and a new normal WCF service. But this shouldn't be such an issue. You don't have to make the troubled "complex type" as a Entity.