I'm building a multi-layered Windows VS C# solution that has a WCF Service Library project with EF6.2 loaded, and an ADO.NET Data layer with EF6.2 also.
The EDMX model is built as a 'database first' set of tables from my MSSQL Server Express 2016 server on my laptop. My WCF Service Interface and code only have properties and methods for one of the tables at this point. And that table has also been built out in logic and data layer methods. So, I'm testing that service now with the WCF Test Client, and I'm receiving some integer data correctly in my service's response from to the data layer, but no string data.
While testing my "GetMemberByID" method, it returns all String column results as a value of "(null)", and a type of "NullObject",
but returns Integers with their actual value. The WCF Soap response shows the returned String values as "". But,
the integers are returned like this: "7". There are over 50 data rows in my test database which is used as the source
for the EF6.2 EDMX build. My App.config's in data and service layers are referencing the same (localdb)\ V13.0 server and database.
Has anyone had this issue, and can you tell me what I'm missing? The MSSQL database was originally an (OleDb) MS Access database and I imported it into MSSQL Server. Thanks in advance.
Okay, I found my mistake. When translating the business domain objects back to the Service objects in the Service.cs code file, I was only translating the MemberID and the RowVersion - and no other columns. So, the only thing that was showing up in the WCF Test Client result was the MemberID and the RowVersion - which happen to be the only two non-strings in my entity. All the string types were null because I was not translating them back into the Service. Thanks for taking a look at this, Abraham, but you made me start looking closer, and thanks for the advice. The MS Documentation was helpful, too. Once I did a full "step into" debug trace from the UI through to the Data Layer and back, I was able to see the data translation failure. One more thing, before I could debug step by step all the way to the Data layer and back to the Service layer, I had to fix my "Underlying database did not open" issue that so many have had. I'm hosting my service through my local IIS, and had to make a few changes to the IIS application concerning the user credentials. My App.config is set to use "Integrated Security=True" - which is a "passthrough" credential in the IIS App pools. I had my IIS App set to "Specific User", but was not using a UserID/Password in my Connection String. Once I changed my IIS App to "Passthrough" - I was able to connect, and to debug to the DAL and back.