LINQ to SQL -Internals -C# - c#

Does LINQ to SQL work in connected environment or disconnected environment? I mean if you compile the query it builds expression query and the query is sent down to sql server ,there it is translated into T-SQL statement and executed and the final result is sent back to the C# code.I hope it is working in connected environment.Is there any framework operates LINQ to SQL in disconnected fashion?

It is connected when it needs to be - i.e. when querying data and when submit changes. If you supply a connection (to the overloaded constructor) that connection will be re-used, otherwise IIRC connection-pooling is used.
For fully disconnected, there are things like "sync services", which builds a local copy of the data.

Related

c# Entity framework's strange behavior with remote mysql database

I am trying to use entity framework 6.1.3 to connect with remote MySql server (MySql.Data.Entity 6.9.9). Connection doesn't fails, but my code do unexpected things:
screenshot
It is interesting, that this code run in expected way on my local MySql DB with exactly same schema and exactly same records.
Does anyone have ideas, why code doen't work on remote DB? How to fix this bug?
EDIT:
Code also works fine, for example, with comparing integer primary key. Problem with string comparation? It's easy exetutes ToList() for all records.
Problem was with charset. Just add "charset=utf8" (my remote db default charset) to connection string.

Use Linq to Sql without connection

I was reading that linq was lazy and that it did not executed the query until it needed to.
if that is the case why does this code fails:
var db = new Data.DataClasses1DataContext(#"Data Source=.\sqlexpress;Initial Catalog=MyDb;Integrated Security=True");
var companies = db.Customers.Where(x => x.Company=="Foo");
var query = companies.ToString();
if I run that code in a computer that does not have sql server installed it will not run why? I am not doing any statement that needs data. If I would call companies.ToList() then its ok for the code to fail. Is there a way I can make use of Linq to SQL Classes without using a connection. I know the moment I do ToList() or try to enumerate through the results I will get an error. I just want to use Linq to Sql Classes in order to generate the SQL statements and see them as a string.
I have a client and a server. The server is a WCF service and the client is a console application. I will send the query encrypted for cases where the user is not entering it. I will like to generate my queries using Linq to Sql classes it does not make sence I have to install sql server on the client just so that I can generate the queries.
My temporary solution is to create a second database on the same server. That database will be allowed to accept remote connections and the whole purpose of it is so that the line
var db = new Data.DataClasses1DataContext(#"some remote connection string");
works. Once I initialize that line I will never need the connection again. It makes no sense.
Do not generate queries on the client then pass the SQL to the service. Instead, generate the lambda expression on the client, and send the expressions to the service.
See "How can I pass a lambda expression to a WCF service?".
One problem this will solve is that of database and schema versioning. TO do it your way would require that the client understand the database schema and even database version, and that it be the same (or compatible) with that which the service uses. Otherwise, you would be stuck having the SQL for one version of SQL Server generated on the client, then sent to a different SQL Server version on the service (or equivalently, a different database schema).
The problem is in the creation of the db context object and not in the linq statement. Specifically, in order to create the db context object you need an actual connection string. If you don't provide one, then the db context you try to create, I suppose it would be null or you will get an exception. Then defining your linq query using this null object will throw an exception, even if your query doesn't use the ToList(), which will definetely force the execution of your linq query.
Reading again your post I believe that you should define in the connection string the sql express server that is installed in the server, which will host the WCF service. Then the client having this connection string would have the ability to make calls to your server database.

Servicestack OrmLite - Execute as User/Impersonation

I am using Servicestack OrmLite as a data layer for my application (.NET C# 3.5/SQL Server).
One of the design requirements (It isn't greenfield, so it is mandatory) is to have commands executed as a particular user which has a schema attached on the SQL server side.
After creating the DbContext with OpenDbConnection() I send an Execute as User command to SQL server so that they are executing with the correct login, and they are switched over to the correct schema for that login.
The error I am getting back for selects against that connection later in the process is:
A severe error occurred on the current command. The results, if any, should be discarded.
Thoughts:
Connection pooling is losing the current user command sent to SQL server?
Is there a built in User/schema handler extension to OrmLite that I haven't seen?
RegisterConnection?
Thanks for your input.

Sql Server isn't closing a connection to linked Server after execution

I am using a linked server to update records in AS/400. It isn't closing the connections properly. On the AS/400 side there are still a number of connections idle. In the sql log it is showing:
EXCEPTION_ACCESS_VIOLATION writing address 0000000000000024 at 0x0000000077BDE4B4
It doesn't appear that it is every time we open a connection and update the file on the AS/400 side. We updated 222 records and there were still 210 connections open. I would expect there to be 222.
We are calling a stored procedure from a .NET app. In the stored procedure we are executing:
EXECUTE (#as400Query) at S100405D
Where the as400Query is a string with the update statement and S100405D is the linked server. The records are getting updated in the AS/400, so that isn't an issue. Just seems that when trying to close the connections, there is an error. Also I checked the settings on the linked server and the connection timeout = 0 (off). Not sure if setting a timeout will close them, or it won't matter because it is throwing an error anyways.
Any help would be greatly appreciated!
Brian
are you submiting any sort of code to close the connection on the AS side? SQL server will only close its connecion, any other connection opened on any other RDBMS won't be managed by SQL
As an IBM i programmer, I would not expect to see any errors during a stored procedure call. Rarely, the OS will throw an exception if there is a parameter mis-match. The most common is the caller (C#) using VARCHAR and the IBM side declaring it as CHAR.
Aside from that, have the IBM people make sure they are current on PTFs.
As a style matter, I would not expect to see:
open connection
CALL proc
close connection
for each row to be updated. Rather, I would expect
open connection
loop
CALL proc
end loop
close connection

SQL Server 2000 Server Errors

The same database and application acts weirdly on our test machine, but it works nice on other computers.
On the test machine:
We get SSL error exception. We fixed that based on an MS KB article, but after that it said
"Server error" or "General network error" and slowed down to 1-2 stored procedures/second.
The profiler said that we have 2000-2500 connections when the application runs. The same application has only 5-10 connection on other machines. I think the random error messages are caused by this huge connection count.
We reinstalled SQL Server, turned off the connection pool, and closed all datareaders.
What else can I do? Is there a "deeper" configuration tool for MSSQL2k? Any hidden component/ini/config/registry key? Or another profiler other than SQL Profiler that I can use?
Yet another possibility(!):
Multiple Fixes for SQL Server .NET Data Provider
When the SQLCommand.CommandTimeout is
set to zero, you expect an infinite
timeout. However, versions 1.1 and 1.0
of the SqlClient provider incorrectly
timeout when a response from SQL
Server is broken into two packets.
Immediately upon receipt of the second
packet, versions 1.1 and 1.0 of the
provider incorrectly timeout. The fix
that is included in this article fixes
this issue so that the command will
have an infinite timeout.
What happens if you turn off OLE DB Resource Pooling?:
'For SQLOLEDB provider
'strConnect = "Provider=SQLOLEDB;server=MyServerName;OLE DB Services = -2;uid=AppUser;pwd=AppUser;initial catalog=northwind"
' For MSDASQL provider
'strConnect = "DSN=SQLNWind;UID=Test;PWD=Test; OLE DB Services= -2"
Another thing to look at is whether you are always specifying the type and direction of stored procedure parameters from ADO.NET.
What happens internally is sqlClient converts the parameters which you have set in ADO.NET to the relevant datatypes in the stored procedure parameters. But this can fail when you are sending nText parameters where it might result in a wrong conversion.
Also, I would check to see if you are sometimes passing very long statements in stored procedure parameters.
Thanx again Mitch, sadly none of those ideas was real solution. No suprise - it seems that those error messages from MSSQL are random.
Random, I mean:
After X[1] concurrent connection MSSQL stops to close connections automatically, and the connection pool grooves huge. Before X, I saw only 5-10 connections[2] / but after that there was 2500 and MSSQL chrased.
In this case, MSSQL throws non deterministic error messages like 'General failure', 'User (null)' etc.
We had unclosed connection in our DAL (hidden since 2 years...brrr), and when we used that to much, it caused this wreid error.
[1] I have no idea about concrete value of X
[2] I've used this query:
SELECT
DB_NAME(dbid) as DBName,
COUNT(dbid) as NumberOfConnections,
loginame as LoginName
FROM
sysprocesses
WHERE
dbid > 0
GROUP BY
dbid, loginame

Categories

Resources