For some reasons, I need to set higher duration for default ConnectionTimeout for asp.net to sql connection. Because some sites, during installing database, which has not connection string yet in web.config, need to execute long sql commands to create sql databases. And I need to allow those installs higher ConnectionTimeout value. Where do I do that? note that there is no connection string key in web.config if database is not created. Thats why I need to change default value.
If there is no connection string which you have created then you can change the timeout like this:
cmd.CommandTimeout = 90; //By default the value is 30
Apply this to the place where you are going to execute your query from the code.
If you want to make the above code a bit generic then you can create the below change in the appsettings.config
<appSettings>
<add key="SqlCommandTimeOut" value="90"/>
</appSettings>
and then you can call it like this:
cmd.CommandTimeout = Convert.ToInt32(System.Configuration.ConfigurationManager.AppSettings["SqlCommandTimeOut"]);
Related
I'm hoping someone can shed some light on this issue. I'm attempting to programmatically add datasources to the Lucee Server context (ie. not on a per-application basis, but rather datasources that are made available to all web contexts on the server). The following call to the tag to create the datasource or later update the same datasource results in the connectionString never being saved correctly.
NOTE: "updateDatasource" will create a datasource if it doesn't already exist.
Host Environment: Windows Server 2019 running Lucee 5.3.8.206 on OpenJDK17.
Database Environment: Windows Server 2019 running SQL Server 2019.
<cfadmin
action="updateDatasource"
type="server"
password="F4K31234"
bundlename="org.lucee.mssql"
bundleversion="8.4.1.jre8"
classname="com.microsoft.sqlserver.jdbc.SQLServerDriver"
dsn="my_new_datasource"
name="my_new_datasource"
newName="my_new_datasource"
connectionString="jdbc:sqlserver://SQLSERVERNAME\MSSQLSERVER2019;DATABASENAME=my_database;sendStringParametersAsUnicode=true;SelectMethod=direct"
dbusername="Temp1234"
dbpassword="F4K31234"
connectionLimit="100"
alwaysSetTimeout="true"
validate="false"
allowed_select="true"
allowed_insert="true"
allowed_update="true"
allowed_delete="true"
allowed_create="true"
allowed_revoke="true"
allowed_alter="true"
allowed_grant="true"
clob="true"
lineTimeout="60">
Every time this operation is attempted, the Connection String is stored as "my_database". In other words, it appears to ignore the string provided in the connectionString attribute and instead stores the database name for the datasource connection string.
These settings are exactly what I use when manually setting up a datasource in the Lucee Server administrative area (minus the obvious fake username, passwords, server names, and database names).
Before I go about filing a bug, I wanted to be sure I'm not missing something here. I appreciate any insight!
I created my vb.net project to .exe file.
During installation on another machine, one can change the location of installing package to any drive.
In my project, I have set my app.config to point the Database that is available in c:\project.
If I suppose, while installation, when I change the location of installation to **d:** or anywhere, I get invalid access db.
What I want is:
I want to reconfigure my app.config file automatically, by detecting its current db location.
Imports System.Configuration
Imports System.Configuration.ConfigurationManager
Dim config As System.Configuration.Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
config.ConnectionStrings.ConnectionStrings("MyProject.Properties.Settings.MyProjectConString").ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;DataSource=|DataDirectory|\SampleDB;Persist Security Info=True;"
config.Save(ConfigurationSaveMode.Modified)
Where MyProject.Properties.Settings.MyProjectConString is the name of your project and connection string.
Although this is too late to answer as the question is very old but I think this might help someone else in the future.
So, there is a way to change the Connection String value in the runtime. Since connection string is a read-only item like all other items that are on Application Scope under My.Settings so we can't change it using My.Setting.ConnectionString = "Something". But here is the code by which you can solve the issue and change any My.Settings item that is on Application Scope in the runtime.
So the code is,
My.Settings.Item("ConnectionString") = "Something"
simple...
MsgBox(My.Settings.Item("remoteAddress").ToString)
My.Settings.Item("remoteAddress") = "abcserver.servebbs.net"
My.Settings.Save()
MsgBox(My.Settings.Item("remoteAddress").ToString)
You have three options:
1.) Create and use a folder in C:\Databse and set your connection string at design time.
2.)Add the database to the project's data source at design time, then use '|Data Directory|\mydb.mdb' as your connection string.
3.) And if you use sqlserver, you don't need to worry about the location of the database once you have attached the database to sqlserver. You only need to use the proper connection string eg 'Data Source=.; Database = mydb; Integrated Security = False; Username=myusername; Password = mypassword; User Instance = false'.
The above is an example of a sql server with SQL Authentication mode as login, if you use Windows Authentication, set Integrated Security = True and remove both username and password.
In Azure, I have a database called Sismos, this was targeted by my WCF service, I created a copy of this database like this on Azure:
CREATE DATABASE sismos_cfe AS COPY OF Sismos;
This was because the initial database was only a for testing and will be used for other purposes and this new one will handle all the work for this WCF servive.
In my WCF service, I changed the following line in my Web.config file:
<connectionStrings>
<add name="Model1Container" connectionString="metadata=res://*/Sismos.csdl|res://*/Sismos.ssdl|res://*/Sismos.msl;
provider=System.Data.SqlClient;provider connection string="data source=*******.database.windows.net;
initial catalog=Sismos;persist security info=True;user id=*******;password=*****;
multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
With this:
<connectionStrings>
<add name="Model1Container" connectionString="metadata=res://*/Sismos.csdl|res://*/Sismos.ssdl|res://*/Sismos.msl;
provider=System.Data.SqlClient;provider connection string="data source=******.database.windows.net;
initial catalog=sismos_cfe;persist security info=True;user id=*****;password=******;
multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
And this line in my app.cofig file:
<connectionStrings>
<add name="Model1Container" connectionString="metadata=res://*/Sismos.csdl|res://*/Sismos.ssdl|res://*/Sismos.msl;
provider=System.Data.SqlClient;provider connection string="data source=******.database.windows.net;
initial catalog=Sismos;persist security info=True;user id=****;password=*****;
multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
With this:
<connectionStrings>
<add name="Model1Container" connectionString="metadata=res://*/Sismos.csdl|res://*/Sismos.ssdl|res://*/Sismos.msl;provider=System.Data.SqlClient;
provider connection string="data source=******.database.windows.net;
initial catalog=sismos_cfe;persist security info=True;user id=****;password=*****;
multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
As you can see, I only replaced the value of the initial catalog property, instead of pointing to Sismos, it now should point to cfe_sismos.
The problem I'm having is that when I try to access one of my endpoints that deals with deleting an entry in the database, no change is made in the database at all. With operations of selecting entries or editing/inserting an entry there's no problem. With the initial catalog property value eing Sismos there's no problem with any of the endpoints, in theory any database access should be directed to the cfe_sismos database.
Was it not enough with me replacing the initial catalog property value? Any help will be appreciated.
EDIT
I just noticed that there's also problems and odd behaviour when editing an entry, for example, if I have an entry in my table Users and I edit the Last_Name, the change won't be reflected when I check my database on Azure, but if I call the endpoint that returns the users, the change will be present, I gave some time to see if there was some kind of delay preventing from showing the newest values in Azure, but it didn't show any changes. How can I be making changes in the database without those changes being shown in the actual database? If I try to insert a new entry into a table, the entry will be shown with no problem.
So in summary, through my endpoints in my WCF service, if I insert something it will be shown in azure, if I edit something it won't be shown in Azure(but the change will be available when calling the respective endpoint) and if I want to delete something it won't be shown in Azure nor the change will be reflected when calling the endpoint.
If the database in Azure is not receiving any changes, then where am I getting all of the information? It's like a cached database exists somewhere, I'm really confused at the reason for this is happening.
I'm really confused at this odd behaviour, so I hope someone can help me. Thanks in advance.
I finally found the reason for the odd behaviour. The thing is that Entity Framework can't work with objects that are copied from another obtained from the Context object generated by Entity Framework.
What I was doing was storing the data from my entities into static Lists to avoid as many connections to the database as possible, only making connections when an insert, update or delete operations were needed. But when I tried to get an object from those lists and use it to update or delete on the database, since it wasn't obtained from the context, then the operations is invalid. This is why only insert operations were working properly, since those are new objects and can interact with no problem with the context.
So in the end I changed the logic for the update and delete operations on my DAO classes, so instead of doing this:
Clusters cluster = (from c in DatabaseInfoHolder.ListaClusters
where c.ClusterId == model.ClusterId select c).FirstOrDefault();
I went with this:
Clusters cluster = (from c in context.Clusters
where c.ClusterId == model.ClusterId select c).FirstOrDefault();
I was hoping for Entity Framework to recognize the values from the object in my static Lists, but it seems it doesn't work that way.
Your config says "initial catalog=sismos_cfe" but you said "CREATE DATABASE cfe_sismos"
sismos_cfe != cfe_sismos
I am struggling with getting a simplemembership scenario working in my EntityFramework / MVC4 / DatabaseFirst project. I've found plenty of examples for working with code first, but nothing for DB first.
The problem I'm encountering is the the InitializeDatabaseConnection is throwing an error ("Unable to find the requested .Net Framework Data Provider. It may not be installed.") The code looks like this :
WebSecurity.InitializeDatabaseConnection("DALEntities", "tblContacts1", "ContactID", "EMail", autoCreateTables: true);
I am not sure what DataProvider is failing. If I try to trace 'into' the InitializeDatabaseConnection call, it immediately throws the error.
What am I missing?
Info:
DALEntities is the name of the connectionString that the rest of EF uses. The following code works just fine....
public ActionResult Test() {
using (var db = new DALEntities()) {
var query = from i in db.TBLINVENTORies
orderby i.ITEMNAME
select i;
var cnt = query.Count();
string str = "Total Inventory: " + cnt;
return Content(str);
}
}
My connection strings section from the web.config:
<connectionStrings>
<add name="DALEntities" connectionString="metadata=res://*/DAL.DAL.csdl|res://*/DAL.DAL.ssdl|res://*/DAL.DAL.msl;provider=System.Data.SqlClient;provider connection string="data source=SOMECOMPUTER;initial catalog=SOMEDB;persist security info=True;user id=SOMEID;password=SOMEPASS;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
</connectionStrings>
This post seems to be asking the same question (but in context of model-first), but there is no solution yet : Using SimpleMembership with EF model-first
Also, I see that there is an overload for WebSecurity.InitializeDatabaseConnection() with the help text: Initializes the membership system ((blah blah <snip> ProviderName: the name of the ADO.NET data provider. If you want to use Microsoft SQL Server, the WebMatrix.WebData.WebSecurity.InitializeDatabaseConnection(String, String, String, String, Boolean) overload is recommended . I do wish to connect to a MSSQL server...will this be required?
The provider giving you trouble is the one specified in your connection string which is System.Data.EntityClient. I suspect the problem is because your project is database-first whereas the simple membership is using code-first. I do not think you can mix these approaches in a single database. Try putting it back to where the DefaultConnection is used for IntializeDatabaseConnection. There should have been a DefaultConnection in your web.config generated by the MVC4 scaffolding. This connection string usually uses System.Data.SqlClient as the provider.
If you want to keep the simple membership in the database used to store domain information (i.e. DALEntities) then you will need to change your method for using EF on the domain to code-first. If you want to keep your project database-first you need to design your own membership schema in the database and develop custom member and role providers. This is probably the best approach if you are really trying to integrate user information into your domain model.
For simplicity and clarity keep two connection strings pointing to the same database. One for EF (doesn't matter if code first or data first) and one for your WebSecurity stuff. (As Chad and Erik said)
<add name="DataEntities" connectionString="metadata=res://*/Models.DataEntities.csdl|res://*/Models.DataEntities.ssdl|res://*/Models.DataEntities.msl;provider=System.Data.SqlClient;provider connection string='data source=[YOUR_SERVER];initial catalog=[YOUR_DATABASE];integrated security=True;MultipleActiveResultSets=True;App=[YOUR_APP_NAME]'" providerName="System.Data.EntityClient" />
<add name="DataDB" connectionString="data source=[YOUR_SERVER];initial catalog=[YOUR_DATABASE];integrated security=True;MultipleActiveResultSets=True;App=[YOUR_APP_NAME]" providerName="System.Data.SqlClient" />
Note that the providers are different: EF uses System.data.EntityClient and non-EF one uses System.Data.SqlClient.
I want to create a dataset.xsd in vs2005, and I am using access database, so I cant know where my client save the application. Hence I used application.startuppath() to get the application folder and appended "Data\db.msd" to the application.startuppath() so i got the target location for the access databse in client machine. Now to create crystal reports I need the dataset.xsd but while creating a new dataset.xsd it was asking the path for the access database, how to programmatically specify the connection string in dataset.xsd so that i can create a connection string. and use that dataset for creating crystal reports.
Thanks in advance
Is it possible that the connection is only used to get the schema of the dataset.
Will you be filling the dataset using a DataReader?
If so i dont think the connection to the dataset is important, it is only to get the schema. You can create the dataset amnually, if it not to mutch effort, and populate it using the appropriate data reader.
You can use AppSettings to store the connection string and retrieve it at runtime. You can then store the connection string information under configuration -> connectionStrings and retrieve it from the application. You could then modify the connection string without having to modify the code.
Your app.settings would look like this (simplified) and replace the ****** with your own connection string:
<configuration>
<connectionStrings>
<add connectionString ="******" name="AccessConnectionString"/>
</connectionStrings>
<appSettings>
</appSettings>
</configuration>
Dim AccessConnectionString As String = System.Configuration.ConfigurationManager.ConnectionStrings.Item("AccessConnectionString").ConnectionString
theConnectionObject.ConnectionString = AccessConnectionString
theDataAdapter.Fill(theDataSet)