I have a web server and its session state is stored in a Sql Server. I need to change the timeout to use an external time source. How would I do this?
Ok, it's not hard to do it. I suppose you're able to read that data from the table - related, as you said, to some User Preference - and to put this data in an int:
int myTimeout = [... read from DB];
It's enough to add this line after the login procedure has been completed (or even during the procedure):
Session.Timeout = myTimeout;
Note: the Timeout is in minutes.
Related
I have a mobile service sync table that is giving me absolutely HORRENDOUS performance.
The table is declared as:
IMobileServiceSyncTable<Myclass> myclassTable;
this.client = new MobileServiceClient("my url here");
var store = new MobileServiceSQLiteStore(“localdb.db”);
store.DefineTable<Myclass>();
this.client.SyncContext.InitializeAsync(store);
this.myclassTable = client.GetSyncTable<Myclass>();
Than later in a button handler I’m calling into:
this.myclassTable.ToCollectionAsync();
The problem is, the performance is horrific. It takes at best minutes and most times just sits there indefinitely.
Is there anything in the above that I’ve done that would explain why performance is so absolutely terrible?
this.myclassTable.ToCollectionAsync();
For IMobileServiceSyncTable table, the above method would execute the SELECT * FROM [Myclass] sql statement against your local sqlite db.
The problem is, the performance is horrific. It takes at best minutes and most times just sits there indefinitely.
AFAIK, when working with offline sync, we may invoke the pull operation for retrieving a subset of the server data, then insert the retrieved data into the local store table. For await this.myclassTable.PullAsync(), it would send request and retrieve the server data with the MaxPageSize in 50, and the client SDK would send another request to confirm whether there has more data and pull them automatically.
In summary, I would recommend you checking with your code to locate the specific code which causes this poor performance. Also, you could leverage adding diagnostic logging, capturing the network traces via Fiddler to troubleshoot with this issue.
I have a webapp designed in asp.net mvc that sends emails via smtp no problem via on click event. But i need a way to automatically check every month for a certification if it is expired and email that user. I am reading sql server or windows service. Which do you recommend and could you provide your link for me to read up on it. Thanks.
Why bother? Sql Server doesn't care about the expiry date...
Joking aside, you'll probably notice that there are a number of internal certs that come with Sql Server that have expired. MS doesn't care about those but you should probably make sure you ignore them in any alert you receive.
You could use a policy (SSMS\Management\Policies) to alert you, something like:
Declare #object_set_id Int
Exec msdb.dbo.sp_syspolicy_add_object_set #object_set_name=N'Certs_ObjectSet', #facet=N'Certificate', #object_set_id=#object_set_id Output
Select #object_set_id
Declare #target_set_id Int
Exec msdb.dbo.sp_syspolicy_add_target_set #object_set_name=N'Certs_ObjectSet', #type_skeleton=N'Server/Database/Certificate', #type=N'CERTIFICATE', #enabled=True, #target_set_id=#target_set_id Output
Select #target_set_id
Exec msdb.dbo.sp_syspolicy_add_target_set_level #target_set_id=#target_set_id, #type_skeleton=N'Server/Database/Certificate', #level_name=N'Certificate', #condition_name=N'', #target_set_level_id=0
Exec msdb.dbo.sp_syspolicy_add_target_set_level #target_set_id=#target_set_id, #type_skeleton=N'Server/Database', #level_name=N'Database', #condition_name=N'', #target_set_level_id=0
Go
Declare #policy_id Int
Exec msdb.dbo.sp_syspolicy_add_policy #name=N'Certs', #condition_name=N'Certs', #execution_mode=0, #policy_id=#policy_id Output, #object_set=N'Certs_ObjectSet'
Select #policy_id
I have a reportviewer (Microsoft.ReportViewer.WebForms) control on my page. All my reports use one data source. I want to be able to let my reports run on a different database when started from my UAT enviroment. So the location of the reports is the same, but the data comes from a different db. I cannot seem to find how this is done, is it even possible?
EDIT: They are server reports on SQL Server . I know you can set the dataset programmaticaly but I just want the reports to point to a different db and leave the rest of the report intact.
2005
TIA,
John
Did you want to pass a full connection string to the report as a parameter? You can do it but sometimes SSRS gets funny and make sure you delete the report off the server before you deploy a new copy when doing this...
1. Make a parameter - let's call ours connectionStr. Make it not null, not blank, single select and text as the data type. Eventually, you will want to hide this parameter but for testing please leave it visible.
2. So the value you will be using as the connection string... (for testing I set this as the default for the parameter, with nothing put under the available values section) Data Source=MySQLServerName;Initial Catalog=MyDatabaseName;Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True
3. You need an unattended execution account on your report server or you get this: unattended execution account is not specified. (rsInvalidDataSourceCredentialSetting). http://msdn.microsoft.com/en-us/library/ms156302.aspx I can't provide more details because my boss had to do this part for me.
4. Under your datasource properties in SSRS... check Embedded Connection, select the type (mine is just a normal MS SQL Server), for the connection string, open the expression box and put: =Parameters!connectionStr.value and then click credentials and make sure the last option for no credentials is selected.
5. Your datasets for that datasource will no longer be happy when you try to edit them in design view but you can switch the datasource connection properties back to how they were, not using the parameter based connection string, for editing them.
My reports are on different servers, with different instances of the Report Server, too. On some servers, they need to get their data from various databases depending on whatever, stuff. This way, with the connection string as a parameter, I can use the same reports everywhere and just deploy them to the different servers. If you are having to pass this connection string around your app or to a report viewer, I suggest using encryption.
Like I said... SSRS get's funny when you start doing this, though. Your reports should always work in preview mode after doing this, if they don't even when provided with the correct connection strings, then you have an issue that won't be solved by just deploying to the server. Trouble shooting problems with this once they are on the server but not working include checking permissions, making sure the report receives the correct connection string and making all your stored procedures and functions within the SQL database are all the same.
If you want to just pass the database name and everything else is the same (server name, username, password) then just set the connection string parameter equal to your database name and for the datasource expression value use
="Data Source=MySQLServerName;Initial Catalog=" + Parameters!connectionString.value + ";Persist Security Info=True;User ID=MyUserNameForTheServer;Password=MyPasswordForTheServer;MultipleActiveResultSets=True"
I needed to pass the whole thing in, and you can play around with the credential settings - you might be able to save the server username/password info in there for each report so that the unattended execution account is not needed.
We recently launched a new web site... there are roughly ~150 users active during peak hours. During peak hours, we are experiencing an issue every few minutes, the exception text is listed below.
System.Web.HttpUnhandledException:
Exception of type 'System.Web.HttpUnhandledException' was thrown.
---> System.Data.SqlClient.SqlException: The client was unable to establish a connection because of an error during connection initialization process before login.
Possible causes include the following:
the client tried to connect to an unsupported version of SQL Server;
the server was too busy to accept new connections;
or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.)
Our data access layer calls various DataTableAdapters using the following syntax.
EDIT
Yes, da is the name assigned to the DataTableAdapter. There is no connection.Open() because the DataTableAdapter takes care of all that, right?
using(TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter da = new TheDataLayer.some.strongly.typedNameTableAdapters.suchAndSuchTableAdapter())
{
StronglyTyped.DataTable dt = new StronglyTyped.DataTable();
da.FillByVariousArguments(dt, ..., ...);
//da.Dispose();
return something;
}
The connection string looks something like:
<add name="MyConnectionString"
connectionString="Data Source=myDBServerName;Initial Catalog=MyDB;User ID=MyUserName;Password=MyPassword"
providerName="System.Data.SqlClient" />
I'm trying to rule the problem being in Code. Is there anything "simple" that can be done to minimize this issue?
Thanks.
Have you tried "Connection Pooling" directly in connection string settings?
Example:
connectionString="....;Pooling=true;Min Pool Size=1;Max Pool Size=10;..."
You can read more info here: http://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.71%29.aspx
Without seeing the code that actually opens and uses the connection, it's hard to say where the problem is.
Please update your question with what happens when you create that DataAdapter (I'm guessing that's what da means).
Also, if you're using the using statement, you shouldn't be disposing of the thing you created the using statement for.
We had similar issue which only happenes in our production environment and it was particularly associated with load. During busy time of day we would recieve several of the above mentioned exception.
We gone through a massive investigation around why this exception occurs and did a lot of changes to fix the issue. The defacto change we did which aleviated the problem was connection pool setting by setting min pool size to 1 and max pool size to 10. (It can vary based on your situation)
This issue will be more prevalent when you have several i.e. 1000's of Customer DB and use default connection string (i.e. database=DBName;server=ServerName). We were not explicitly setting min/max pool size hence it took default settings which set Min pool size to 0 and max pool size to 100.
Again, I dont have concrete proof but the theory is that during busy time of the day based on load it made several connection to DB server and DB server was bombarded with a lot of connection request at single point to several databases. Either Application server or DB server did have bandwidth to handle that many connection in a short period of time. Also, it was happening with server with most databases. Though we did not see a lot of connection at a time but Application server was not able to make connection to databases for a short duration when it had surge of requests going in.
After we set min pool size we aliveated this problem as there is atleast one connection to each database which is available all the time and if there is blast of request which required to make connection to several databases we already had atleast one connection to the database available before we request a new one.
Maybe unrelated to the actual problem you were facing, but this error is also thrown if you are trying to connect without specifying the correct port along with the database server name.
Why Session objects are not removed after Timeout period?
I am using Asp.Net 4.0 and Session state is configured as shown below.
<sessionState mode="SQLServer" cookieless="false" timeout="5"
allowCustomSqlDatabase="true"
sqlConnectionString="data source=.\SqlExpress;initial catalog=App_SessionState;user id=sa;password=xxxxxxxx"/>
If I have not activity in browser for about 10 mins, shouldn't the Session object be removed. But after 10 mins I can still access the Session variable. Am I missing something here?
EDIT:
If I access a session variable after 10 mins as shown below shouldn't I get NULL
var myObj = Session["MyKey"] as MyClass;
mObj is not NULL after 10 mins.
There's a stored procedure installed called DeleteExpiredSessions, called from the job ASPState_Job_DeleteExpiredSessions, and is executed every minute (if I read the InstallSqlState.sql file correctly).
The procedure basically calls DELETE FROM ASPStateTempSessions WHERE Expires < GETUTCDATE()
So, if objects aren't removed, check the Expires column, and verify that you're comparing with the utc date. If in doubt, do a SELECT * FROM ASPStateTempSessions WHERE Expires < GETUTCDATE(). Also, make sure that your ASPState_Job_DeleteExpiresSessions is enabled and working.
A quick (and totally unconfirmed idea); do SQL Server Express come with the SQL Agent? Is it enabled and able execute scheduled jobs?
The "session" is never "null", but after the timeout has expired, the session object is emptied (or re-instantiated), another session is automatically started (you can check this by handling SessionEnd and SessionStart events), and you will always have a reference to a session object.
Does not happen? Still you see previous session's data?
To add onto what Simon said, If there is no SQL Server Agent running there will be no clearing of session values unless a stored procedure inside of the database is actually executed.
I don't think SQL Server express has the Agent so an automated job is not possible.
If you have control of the server then I would suggest setting up a scheduled task through windows that executes the stored procedure or job that clears your expired sessions. I don't know the exact name of the stored procedure right now but it should be named fairly obvious to it's purpose.
So your options are to upgrade to a version of SQL server that has the SQL Server Agent available or set something up to manually execute the stored procedure to clear expired sessions.
Alliteratively you can use InProc sessions, which are cleared automatically. But I assumed since InProc is the default there is a reason why you switched to SQL Server.