With my source in Subversion, I am having issues when 2 different computers have different connection strings.
The LINQ to SQL designer seems to only like having the same connection string.
Is it possible for the designer to use a connection string that varies since developers have different local configurations, but the actual usage in the web application pulls from the web.config?
Unfortunately, this is a huge source of pain with the LINQ to SQL designer. I do not know of a way to force visual studio to never add a default connection string when you drag tables or stored procedures onto the design surface.
We work around the issue thusly:
we never save our dev passwords
we never use the default connection string in code when newing up a DataContext
we can therefore "safely" ignore the multiple connection strings during sprints that touch the data layer
when things die down/become more stable, we delete the connection strings from the data context, either using properties of the designer surface itself or by editing the XML. At that point, it's up to the modifier of the data context to keep up with deleting the default connection strings.
Alas, this is not an ideal situation. Hopefully VS2010 will "fix" this issue.
I ran into this problem and found your question. Here's the solution we're now using:
Use a centralised Configuration class for retrieving config values from a particular location on the file system. This allows every machine where the code is running to use its own config values.
Create a partial class for the LINQ to SQL data context. Add a custom constructor that takes no parameters and retrieves the database connection string from the Configuration class described above.
For example:
public partial class MyCustomDBDataContext
{
public MyCustomDBDataContext() :
base(Configuration.GetDatabaseConnectionString())
{
}
}
This should now solve the problem both for developers and when deployed to test and production.
By following the guidelines on How Do I? Change Connection String of datacontext default constructor from web.config my application now uses different connectionstrings depending on if HttpContext.Current.Request is local or not.
//using System.Web.Configuration;
partial void OnCreated()
{
//Change this condition to your needs
var isLocal = HttpContext.Current.Request.IsLocal;
this.Connection.ConnectionString = WebConfigurationManager.ConnectionStrings[isLocal ? "localConnectionstring" : "otherConnectionstring"].ToString();
}
Related
After getting this error :
MySqlException: There is already an open DataReader associated with
this Connection which must be closed first.
I was unable to request or get result sets because i was querying while EF was still lazy loading other stuff that i had previously requested.
Found many possible solutions to address this issue which i have shared as an answer below.
If you don't mention the type loading in EF configuration, EF will by default use Lazy Loading.
There are various ways to over come the 'Connection is open issue':
By adding MARS to your EF connection string, please also read this before jumping into it.
Use 'USING' statement, but for this you need to create a new entity object every time it gets disposed.
Convert your result to Generics types or into local object types in my case i converted it ToList() which helped address my issue and i was able to request a new result set from the context.
I have a base class that provides me with the context object, which is why i didn't use Using statement to create new context every-time i wanted to query the context.
feel free to edit any mistakes, still learning about EF and its behavior.
I am looking for a solution to effectively communicate between two running MS Access applications.
The approaches I tried so far is to use a common linked table and to use MSMQ service for communication. Both approaches work, but there is no way to "push" the data or command from one application to another and since MS Access doesn't support multi-threaded execution of VBA code, it is very difficult to implement polling without performance disadvantages.
Same time, VBA does support the addressof operator (from version 2000) that means we can also theoretically implement call-back functions in VBA and MS Access. But I have never seen any example how this can be used for inter-process communication and would appreciate any minimal example how I can send a string from one MS Access application to another without monitoring a shared table all the time.
You can use GetObject() to return the Access.Application object from another running db. With the application object you have access to just about everything you might need. Here's a contrived example of opening a form (but you can do a myriad of other things with the Application object):
Sub TestInterop()
Const mdbPath As String = "C:\OtherApp.mdb"
Dim OtherApp As Access.Application
Set OtherApp = GetObject(mdbPath)
OtherApp.Visible = True
OtherApp.DoCmd.OpenForm "Accounts"
End Sub
If the program is not already running, the GetObject() call will start the application (you would need to be careful if you have multiple versions of Access installed as it's difficult to know at runtime which version would actually open the .mdb). However, if GetObject() needs to start the app, it will do so with the visibility set to False, so we explicitly set it to True. If the app is already running, setting its Visibility to True will have no effect.
Consider it a wild idea, but may be put all your tables into sql express and/or sql ce and make look like a frontend to those tables?
Fairly simple question that I can't remember. We have three environments: Local machine (unique for each developer), Development, and Production. Connection Strings are in a config file (not web.config, but web.config points to the file); only one is active at a given time (the other two are commented out; all three have the same name but different values for each environment).
I'm using a rudimentary version of the ActiveRecord pattern to handle data access (i.e. static GetByProperty methods in the Linq-generated CS file). To ensure that all of us can use the Linq classes without having to muck about with the designer, all I would have to do is pass in that configuration setting with the connection string (e.g. ConfigurationManager.AppSetting["TheConnectionString"]) when I new up the DataContext, correct? I am going the approach of newing up a context per request; is there any issue (other than DRY, as I'd be repeating the whole connection string every method) I should be aware of passing the connection string in every time, or is that standard operating procedure?
You chose two of my least favorite things (ActiveRecord and LINQ to SQL). ;-) Regardless, you can move the code to a factory method (or similar) to avoid the DRY issue, if that particularly bugs you. You will likely have to do a small bit of refactoring and re-architecting, but you can solve that issue later.
As for changing connection strings to be environment specific, that is fairly standard operating procedure, whether you are using LINQ, DataSets, EF, or otherwise. Location of the actual persistant store is a configuration issue.
DataContext has Connection property of type DbConnection and I was wondering if I could re-use it. I've tried to use it creating a command using CreateCommand and using a reader off of it but I've gotten errors saying there is a pending transaction or something similar.
Basically I'm trying to find out if there is a best practice or guidance on re-using that connection object.
The connection string itself doesn't really help since I can't create a new connection object with the abstract type and I don't want the code to know the specific provider type either.
One alternative approach I'm thinking of doing is having my DataContext derived type to have members that provide a factory method to create a new connection using the same connection information.
FYI, this inquiry stems from the need to invoke an ad-hoc stored procedure through DataContext, not the design-time ExecuteMethodCall variety. I didn't know about ExecuteQuery and for now that suffices. But for other situations where ExecuteQuery is inadequate, I'd need the low-level data access using connection/command etc.
Why not turn it around, and instead supply connections to the datacontext by using the constructor that takes a connection as a parameter? That way you can control when connections are created and disposed, opened and closed, and can reuse them for other purposes without having to worry about the internal behavior of the L2S datacontext...
I can't say definitely, but a connection is a connection. Until it's been closed (or returned to the connection pool), it should be viable to use, whether via LINQ or other means.
I am using Visual Studio 2010, and I have a LINQ-to-SQL DBML file that my colleagues and I are using for this project.
We have a connection string in the web.config file that the DBML is using. However, when I drag a new table from my "Server Explorer" onto the DBML file... I get presented with a dialog that demands that do one of these two options:
Allow visual studio to change the connection string to match the one in my solution explorer.
Cancel the operation (meaning, I don't get my table).
I don't really care too much about the debate as why the PMs/devs who made this tool didn't allow a third option - "Create the object anyway - don't worry, I'm a developer!"
What I am thinking would be a good solution is if I can create a connection in the Server Explorer - WITHOUT A WIZARD. If I can just paste a connection string, that would be awesome! Because then the DBML designer won't freak out on me :O)
If anyone knows the answer to this question, or how to do the above, please lemme know!
Here is a similar thread that has a couple of options. Unfortunately all of them are a bit of a work around, but it seems like the best current solution to the problem. Managing different developer's connection strings under LINQ to SQL
Suppose you are generatung a SampleDataContext class.
Create another file, say called SampleDataContext.cs and add the following
public partial class SampleDataContext
{
partial void OnCreated()
{
Connection.ConnectionString = System.Configuration.ConfigurationManager.AppSettings["SQL"];
}
}
So now it does not matter which database connection you use in the designer; the connection string to be used will be pulled from your app settings.