I'm looking for a feature much like the Log property in Linq DataContext.
All executed SQL is written to the Trace, so you can access is using a TraceListener.
Related
if I implement the following api toystore.com/api/toys?$select=prodId&$filter=startswith(CompanyId,'lego') in ASP.NET, MVC, using odata3 and EF. Does that query get evaluated on my database (which is indexed and good at filtering) or do I retrieve all 100k rows and then filter them on my IIS webserver in memory? If it's the latter is there a way to make this more performant. thanks
edit - clarifying...
"can" asp.net odata queries ever filter on the database or are they always evaluated on the IIS?
related: Enable lazy loading on OData URL Query
If you return with IQueryable, where condition will be added in sql query. Thus, it will not pull all the data from the database. If you return an IEnumerable instead of IQueryable, it will pull all the data and filter it in iis.
I hope I have helped.
Using ServiceStack ORMLite https://github.com/ServiceStack/ServiceStack.OrmLite I want to trace certain database calls with CaptureSqlFilter or some similar technique. However when you use this filter it captures the "intended" SQL but stops the commands actually being executed. This appears to be by design.
I want to use this or a similar technique to trace the ACTUAL calls made to the DB without stopping them.
Note that I want to do this in the code, I'm using SQL Azure so can't readily use SQL Profiler etc to achieve a similar result.
Thanks.
If you enable a Logger with Debug enabled it will log the SQL to your registered Logging Provider.
Otherwise you can also enable ServiceStack's built-in Mini Profiler which will provide access to the executed SQL.
I have a program in which it insert a raw in a table after certain operations. I wan to call a web service in code behind to do some special tasks by the using of info that there is in the inserted row.
How I can do that?
Is it good idea to invoke this web service from a stored procedure or not? What are the other options?
More Details: Actually, I have an operation in my web application that take a long time to be completed and it is seriously time consuming operation. I don't want client wait until this process finish. That is why I decide write a web service to do this process in the background.
Therefore, I think it may be a good idea that when client request receive I insert his request in a table and call a web service to handle it. Moreover, I do not want to wait until web service return the result, so I will aware client from its result through the report. I do not know what is the best solution to handle it.
I usually keep myself far away from table triggers(it sounds like you're about to use an on insert trigger for a table).
I don't know your specific situation but you could either :
Call the webservice before or after you call the stored procedure, this way the data layer(stored proc) only handles data and nothing more. You're logical layer will handle the logic of calling an extra webservice.
Write a service that will periodicly read a table and notify the webservice of the latest modifications. More messy but it resembles more the effect you're trying to achieve.
There are probably more solutions but i'd need more information on what it exactly is you're doing. Right now it's kinda vague :)
It is never a good idea to call webservice from Stored procs or other DB objects. You can call it from your code, just after you execute the insert and commit it.
The problem it sounds like is that you cannot guarantee that the web service will be called unless you call it before committing the transaction. However, it sounds like the web service needs to be called after commit. In this case, it sounds like you should use a message queue. You could either build one in your database or you could use one off the shelf (http://aws.amazon.com/sqs/ or http://www.windowsazure.com/en-us/home/features/messaging/).
The steps would be:
Insert message into queue (after this is success you can return the call, depending on what your contract with the caller is)
Read message
Insert into table
Call web service
Delete message
The downside is that you will need to make the operations (inserting into the table and calling the web service) idempotent.
I want to know , If I can catch all errors occurred in my database and log it to some user defined table.
Reason:
Why I am as so is that, I have web-app running with Sql2005 as backend. Web app is developed using Linq2Sql. It was developed on 2008R2 where as deployed over Sql2005 on a Shared Hosting environment.
I am continuously getting datetime datatype error, as in 2008 i have used date datatype.
So, what I want is to catch any similar exceptions internally , occurred anywhere in my database and log it to my custom table with fields
Requirements
Table Name from where the exception has been thrown
Name of Procedure, in case if I use it in future
Exception message
Date time of occurrence
Please Note
I dont want to write tablewise exception handling procedures. I want some generic way to get all exceptions, as same as we handle errors in ASP.Net , Global.asax.
Exception I am getting
The version of SQL Server in use does not support datatype 'date'.
based on above exception, I am not sure which table is throwing this exception. So I want a stored procedure to catch the detail and save to my custom table.
Those errors aren't internal to SQL server. It's probably not even SQL that's giving it to you but rather the db drivers.
If you are using stored procedures, then SQL server would have prevented those s'procs from even being created with the unsupported data type usage.
Considering you are using LINQ, my guess is that LINQ itself is throwing the problem and you'll need to use your regular exception handling around database calls to find it.
Of course, a better path, would be to regenerate your model and/or do a code analysis to locate all references to invalid data types. Or, even better, switch to a host that is somewhat up to date with their version of SQL server. There have been a lot of security and performance improvements since then.
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