Right now I'm currently converting WCF web service to DataTable (we know this can get messy), then planning to convert it to SQL Db Type. I was thinking, can't I just consume the WCF service as a SQL Db Type? If so, I've searched and couldn't find a solution to this. What I'm planning to do is sending the DataTable over Sql Data Type.
There exists this approach: http://sharpfellows.com/post/Returning-a-DataTable-over-SqlContextPipe. However, that's a 2006 article and I'd like to skip the .net DataTable.
Code example of how to read WCF as SQL datatype would be much appreciated, thanks!
A DataReader is a class that keep connection open with database, so you cannot consume a service that returns a DataReader.
And return a DataTable is equals a bad idea, you must read the data and return a class with just data.
Maybe a good solution to your scenario can be WCF Data Services, that do what you want: data access.
You can read more here: https://msdn.microsoft.com/en-us/library/cc668794(v=vs.110).aspx
Related
This is a question to improve my understanding about OData and the process of OData services. I'm not sure about the process when an OData request is sent to the server from my Fiori app. The app is added to our Fiori Launchpad. When the user wants to create a new target group in the UI, a create request is sent. What happens then in detail? What I thought so far:
OData service checks the data
If the data is valid, a new entry in the database is created (HTTP POST)
If the data is not valid, the OData service sends an error
I'm not sure about what information is delivered by the OData service and what information is delivered directly from the database? Does the OData service work like a adjustor which transfers the messages sent from the database to the application?
I hope you can understand what I'm trying to figure out. Thank you for your time.
it depends how your backend-methods are implemented. Every Entityset usually has one of these Methods:
Get Entity
Get EntitySet
Create
Update
Delete
There are some more I guess, but these are mostly used by developers. You can redefine every single method and implement your own Business Logic in there.
So, let's assume you want to send data from the Frontend to your service and insert the data into a table inside your database. You have to redefine the create method of your entity and implement own logic. This could contain an insert into a database-table. You have to consider, that your oData Service will throw an Error if the types which are sent from the frontend do not match the Entity-Types (i.e. a String into an edm.Time type).
Here you can find all EDM.Types oData could consume and the correct mapping of the types:
https://help.sap.com/saphelp_gateway20sp12/helpdata/en/76/4a837928fa4751ab6e0a50a2a4a56b/frameset.htm
Hope this helps :)
I'm very new at WCF (and .NET in general), so I apologize if this is common knowledge.
I'm designing a WCF solution (currently using Entity Framework to access the database). I want to grab a (possibly very large) set of data from the database, and return it to the client, but I don't want to serialize the entire set of data over the wire all at once, due to performance concerns.
I'd like to operation to return some sort of object to the client that represents the resulting data and I'd like to deal with that data on the client, being able to navigate through it backwards and forwards and retrieve the actual data over the wire as needed.
I don't want to write a lot client code to individually find out what rows meet my search criteria, then make separate calls to get each record if I can help it. I'm trying to keep the client as simple as possible.
Ideally, I'd like to write the client code similar to something like the below pseudocode:
Reference1.Service1Client MyService = new Reference1.Service1Client("Service1");
DelayedDataSet<MyRecordType> MyResultSet = MyService.GetAllCustomers();
MyResultSet.First();
while (!MyResultSet.Eof)
{
Console.Writeline(MyResultSet.CurrentRecord().CUSTFNAME + " " + MyResultSet.CurrentRecord().CUSTLNAME);
Console.Writeline("Press Enter to see the next customer");
Console.Readline();
MyResultSet.Next();
}
Of course, DelayedDataSet is something I just made up, and I'm hoping something like it exists in .NET.
The call to MyService.GetAllCustomers() would return this DelayedDataSet object, with would not actually contain the actual records. The actual data wouldn't come over the wire until CurrentRecord() is called. Next() and Previous() would simply update a cursor on the server side to point to the appropriate record. I don't want the client to have any direct visibility to the database or Entity Framework.
I'm guessing that the way I wrote the code probably won't work over WCF, and that the functions like CurrentRecord(), Next(), First(), etc. would have to be separate service contract operations. I guess I'm just looking for a way to do this without having to write all my own code to cache the results on the server, somehow persist the data sets server side, write all the retrieval and navigation code in my service library, etc. I'm hoping most of this is already done for me.
It seems like this would be a very commonly needed function. So, does something like this exist?
-Joe
No, that's not what WCF is designed to do.
In WCF, the very basic core architecture is that you have a client and a server, and nothing but (XML-)serialized data going between the two over the wire.
WCF is not a remote-procedure call method, or some sort of remote object mechanism - there is no connection between the client and the server except the serialized message that conforms to the service (and data) contracts defined between the two.
WCF is not designed to handle huge data volumes - it's designed to handle individual messages (GetCustomerByID(42) and such). Since WCF is from the ground up designed to be interoperable with other platforms (non - .NET, too - like Java, Ruby etc.) you should definitely not be using heavy-weight .NET specific types like DataSet anyway - use proper objects.
Also, since WCF ultimately serializes everything to XML and send it across a wire, all the data being passed must be expressible in XML schema - which excludes interfaces and/or generics.
From what I'm reading in your post, what you're looking for is more of a "in-proc" data access layer - not a service level. So if you want to keep going down this path, you should investigate the repository and unit-of-work patterns in conjunction with Entity Framework.
More info:
MSDN: What is Windows Communication Foundation?
WCF Essentials—A Developer's Primer
Picture of the very basic WCF architecture from that Primer - there's only a wire with a serialized message connecting client and server - nothing more; but serialization will always happen
I want to consume a .NET web-service that will accept SQL statement, for example: select * from my_table order by name and will return that dataset to my Delphi ClientDataSet / disconnected TADODataSet, and will display the result in the TDBGrid.
Part 2) After I update a single record I want to be able to update the .NET dataset via a webservice.
How can I do that? (Code Please)
1) .Net datasets uses XML to transfer it's data, so you can read them as XML then convert them to Delphi Dataset, Look at these articles
Use ADO.NET Datasets in Delphi
Working with .NET data in Delphi
2) As I understand you will using Web services, so it will be better to add an update method to your service and call it to update the data.
One note, IMO, sending raw SQL to web services as the way you would like to use is a bad design, I prefer you to do define your business logic as group of methods, then call them as your application needs.
Also you can use Delphi Prism for more easier and better .Net integration
How to create a JSON webservice in ASP.NET that connect to MS SQL Database and update/delete values from the database?
This webservice will eventually be used to communicate with iPhone SDK.
Any help would be appreciated.
Thanks!
You could do this:
1) Make a data access layer of some sort.
Example: Linq to SQL, Entity Framework, SubSonic, nHibernate, ADO.Net
2) Create a web service (.asmx file) which calls your data access.
3) Make methods in the web service which return json seralized objects or what not.
[WebMethod]
public Item GetSingleItem()
{
return DataStore.FetchItem(); // return a single object
}
4) Have a client which can send parameters to the web service and then consume the returned json. I'm thinking that your client on the iPhone will either be a native iPhone application or a web application run through the phones browser. Either way, this sounds like a neat idea.
Good luck, and hope this short list helps you out some.
I'm making my first WCF Service and I am unsure which route I should take with stored procedures and Linq to Sql. I understand that I can drag and drop stored procs to my DBML file and call them that way, or call them directly, not using the dbml. Is there a reason why i should choose one over the other? I guess I'm a little confused... Any input is greatly appreciated!
Well, do you already have a Linq-to-SQL data model, which you use in your WCF service? If so, I would probably put my stored procedures into that data model.
If you don't already have and use a Linq-to-SQL data model, I don't really see much use and sense in creating one just to be able to call a stored procedure.
If you don't already have a Linq-to-SQL data model, I'd probably just use the straight ADO.NET code to call that stored procedure, send in any parameters coming from the WCF service method, and passing back any data you need to send back. In that case, you'd use a SqlConnection, a SqlCommand (CommandType set to StoredProcedure), a bunch of SqlParameters, and then call the command.ExecuteNonQuery() or command.ExecuteReader() methods (depending on what your stored proc is doing).
If you come across a situation in which you may need to manipulate the arguments of the stored procedure dynamically, you may want to create a class that calls the stored procedure via WCF Service. Check how is done in this post.
Executing SPs from WCF Service