Классная штука!
Google предлагает большое количество сервисов и API. К счастью они также предоставляет простой способ тестирования, изучения и создания любых приложений в Code Playground. Получите доступ к примерам API, сделайте в них изменения, отладьте, сохраните и экспортируйте свою работу.
Ссылка
воскресенье, 15 ноября 2009 г.
четверг, 12 ноября 2009 г.
пятница, 6 ноября 2009 г.
SQL-полезное (Fixing broken users after Database Restore)
Решение
В комментариях прикольно - I've been using this command since 5 years... and I always forget the syntax
Надо ж - таже фигня!!!
USE db_name
GO
EXEC sp_change_users_login 'Auto_Fix', 'user_name', NULL, 'password'
GO
В комментариях прикольно - I've been using this command since 5 years... and I always forget the syntax
Надо ж - таже фигня!!!
USE db_name
GO
EXEC sp_change_users_login 'Auto_Fix', 'user_name', NULL, 'password'
GO
вторник, 3 ноября 2009 г.
IVR-ссылки (Outbound+MSMQ+Service Unavailable+503)
Долго боролись с проблемой "зависания" приложения (оказалось просто MSMQ "банилась")
в ситуации когда при звонке на некоторые телефоны возвращалась ошибка 503 ServiceUnavailable
Вот как надо это лечить
еще
еще
Кроме того после выставления SipPeerException.ShouldThrottleMsmqCalls = false
у нас прекращались все события от SipPeerException (например обработка от this.TelephonySession.Close()), пришлось сделать "трюк" - заводили свой таймер и после истечения времени выставляли там статус звонка
Далее статья с первой ссылкой выше ...
One of the most common ways of queuing outbound calls with Speech Server is by using the built in MSMQ support. For the most part, using a message queue is extremely straightforward and easy to implement. But there is one gotcha – call throttling.
When an outbound call fails to connect, Speech Server will start throttling down the number of messages it pulls from the queue. The assumption is that failures are the result of your system having insufficient capacity to handle the load. The more failures your have, the more it will throttle the load. This would be acceptable if it were not for two issues:
Almost any failure, even acceptable ones, can result in throttling
It will happy throttle you all the way down to 0, effectively shutting down your application
Disabling call throttling needs to be done on a per-call bases by binding to the TelephonySession.OpenCompleted event prior to the MakeCall Activity. Typically I do this in a Code Activity at the very top of my workflow.
Inside my initWorkflow Activity I bind to the OpenCompleted like so:
TelephonySession.OpenCompleted += new EventHandler(TelephonySession_OpenCompleted);
Then I use the following to disable throttling on any failure:
void TelephonySession_OpenCompleted(object sender, Microsoft.SpeechServer.AsyncCompletedEventArgs e)
{
if (e.Error != null && e.Error is SipPeerException)
{
SipPeerException sipEx = e.Error as SipPeerException;
sipEx.ShouldThrottleMsmqCalls = false;
}
}
в ситуации когда при звонке на некоторые телефоны возвращалась ошибка 503 ServiceUnavailable
Вот как надо это лечить
еще
еще
Кроме того после выставления SipPeerException.ShouldThrottleMsmqCalls = false
у нас прекращались все события от SipPeerException (например обработка от this.TelephonySession.Close()), пришлось сделать "трюк" - заводили свой таймер и после истечения времени выставляли там статус звонка
Далее статья с первой ссылкой выше ...
One of the most common ways of queuing outbound calls with Speech Server is by using the built in MSMQ support. For the most part, using a message queue is extremely straightforward and easy to implement. But there is one gotcha – call throttling.
When an outbound call fails to connect, Speech Server will start throttling down the number of messages it pulls from the queue. The assumption is that failures are the result of your system having insufficient capacity to handle the load. The more failures your have, the more it will throttle the load. This would be acceptable if it were not for two issues:
Almost any failure, even acceptable ones, can result in throttling
It will happy throttle you all the way down to 0, effectively shutting down your application
Disabling call throttling needs to be done on a per-call bases by binding to the TelephonySession.OpenCompleted event prior to the MakeCall Activity. Typically I do this in a Code Activity at the very top of my workflow.
Inside my initWorkflow Activity I bind to the OpenCompleted like so:
TelephonySession.OpenCompleted += new EventHandler
Then I use the following to disable throttling on any failure:
void TelephonySession_OpenCompleted(object sender, Microsoft.SpeechServer.AsyncCompletedEventArgs e)
{
if (e.Error != null && e.Error is SipPeerException)
{
SipPeerException sipEx = e.Error as SipPeerException;
sipEx.ShouldThrottleMsmqCalls = false;
}
}
среда, 28 октября 2009 г.
ASP.NET - полезное (Five common mistakes in the web.config file)
Five common mistakes in the web.config file
Коротко без описаний:
1. Custom Errors Disabled
customErrors mode="RemoteOnly"
2. Leaving Tracing Enabled in Web-Based Applications
trace enabled="false" localOnly="true"
3. Debugging Enabled
compilation debug="false"
4. Cookies Accessible through Client-Side Script
httpCookies httpOnlyCookies="true"
5. Cookieless Session State Enabled
sessionState cookieless="UseCookies"
Коротко без описаний:
1. Custom Errors Disabled
customErrors mode="RemoteOnly"
2. Leaving Tracing Enabled in Web-Based Applications
trace enabled="false" localOnly="true"
3. Debugging Enabled
compilation debug="false"
4. Cookies Accessible through Client-Side Script
httpCookies httpOnlyCookies="true"
5. Cookieless Session State Enabled
sessionState cookieless="UseCookies"
четверг, 24 сентября 2009 г.
SQL-ссылки (восстановление базы fullbackup+LDF))
http://blogs.msdn.com/suhde/archive/2009/05/18/database-corruption-part-4-recovering-from-a-failed-disk.aspx
Database Corruption Part 4 :: Recovering from a failed disk
It was a nice day a few days back - nice sunny day, with moderate temperatures. I got up early and after spending some time reading my favorite articles, made my way to office. In office, I realized I hadn't much work lying ahead; so sat down wondering how to account for my day.
Suddenly the phone on my desk rang - tring! tring!
"Hi, this is Suhas. How can I help you?"
"I... I lost my disk...!"
"What!"
"My disk crashed. It had my database..."
"You mean the database files?"
"Yes. I had two disks, one had the mdf file and the other had the ldf."
"And, you lost both?"
"No, just one..."
"Ok, so which one did you loose?"
"The one that had the mdf."
"Oh boy! Do you have a backup of the database."
"I do, but it's over 6 months old... Please help me get my data back. You know, I will get fired if I loose the data..."
That's how the conversation started that day. Needless to say, this is one of the situations you would not like to see yourselves in. However, in PSS, we do come across situations like this, when going back to the last backup is not an option, and we have to recover as much data as possible. However, as I have already mentioned in my first blog on Database Corruption, Microsoft Product Support Services (PSS) does not guarantee that if you call in with a database corruption issue, PSS would recover all your data. All support that PSS provides in corruption cases is on "best efforts basis", meaning that PSS will provide commercially reasonable efforts to recover your database or data off your corrupted database using documented and undocumented commands and procedures. However, 100% data recovery is not guaranteed.
In this case, however, we were able to recover the database back. There were multiple points of failure; however, luck was on our side. Here is what we did:
First thing that we did is:
RESTORE HEADERONLY FROM DISK = 'Full path to the backup set'
We were basically looking for 2 options, the Recovery Model and the Backup Type.
Had the Recovery Model been "Simple" or "Bulk-Logged", the story would have ended there itself. Moreover, at this point, we are still not sure if the Database Recovery Model had been changed; we were trying our luck. Had it been changed, that would have been the end of the story as well. Also, the Backup Type was "Full", so, we were good to go with this backup.
We now stopped the SQL Server instance and renamed the existing log file (the LDF file). We had actually planned to drop this database, and we did not want the LDF file to get deleted.
Now, we started the SQL Server and dropped the database. Drop completed successfully, leaving behind the LDF file.
At this point, we created a new database, and pointed the LDF file of the new database to the location where the old LDF file existed. This was to save us the task of copying the old LDF file over to the new location; the old LDF file was about 300 GB in size.
We now stopped the SQL Server, and replaced the LDF file of the newly created database by the old LDF file.
We started the SQL Server, and, as expected, the database was in Suspect Mode.
We now, issued the following command:
BACKUP LOG DatabaseName
TO DISK = 'Full path to TRN Backup file'
WITH NO_TRUNCATE
This command completed successfully and we had a Tail Backup of the Log File. I would like to mention here, that we had a point-of-failure here. Had the Recovery Model of the database been changed after the Full Backup, this command would have failed.
Now, we were all set to restore the database. So, we proceeded with restoring the Full Backup. We issued the command:
RESTORE DATABASE NewDatabaseName
FROM DISK = Full path to the FULL Backup'
WITH
MOVE 'Data File Name' TO 'Full path to MDF File location',
MOVE 'Log File Name' TO 'Full path to LDF File location',
NORECOVERY
The Full Backup was restored and the database was in Recovering Mode.
Next step was to restore the Log Backup. We issued the command:
RESTORE LOG DatabaseName
FROM DISK = 'Full path to LDF File location'
WITH RECOVERY
The backup restored successfully, and the database was back up online!!
Here, again, we had a point of failure. If the Full Backup that we had restored not been the Last Full Backup; meaning, had there been another Full Backup after the backup set we had restored, the restoration of the Tail Log Backup would have failed!
However, we WERE lucky!!!
Database Corruption Part 4 :: Recovering from a failed disk
It was a nice day a few days back - nice sunny day, with moderate temperatures. I got up early and after spending some time reading my favorite articles, made my way to office. In office, I realized I hadn't much work lying ahead; so sat down wondering how to account for my day.
Suddenly the phone on my desk rang - tring! tring!
"Hi, this is Suhas. How can I help you?"
"I... I lost my disk...!"
"What!"
"My disk crashed. It had my database..."
"You mean the database files?"
"Yes. I had two disks, one had the mdf file and the other had the ldf."
"And, you lost both?"
"No, just one..."
"Ok, so which one did you loose?"
"The one that had the mdf."
"Oh boy! Do you have a backup of the database."
"I do, but it's over 6 months old... Please help me get my data back. You know, I will get fired if I loose the data..."
That's how the conversation started that day. Needless to say, this is one of the situations you would not like to see yourselves in. However, in PSS, we do come across situations like this, when going back to the last backup is not an option, and we have to recover as much data as possible. However, as I have already mentioned in my first blog on Database Corruption, Microsoft Product Support Services (PSS) does not guarantee that if you call in with a database corruption issue, PSS would recover all your data. All support that PSS provides in corruption cases is on "best efforts basis", meaning that PSS will provide commercially reasonable efforts to recover your database or data off your corrupted database using documented and undocumented commands and procedures. However, 100% data recovery is not guaranteed.
In this case, however, we were able to recover the database back. There were multiple points of failure; however, luck was on our side. Here is what we did:
First thing that we did is:
RESTORE HEADERONLY FROM DISK = 'Full path to the backup set'
We were basically looking for 2 options, the Recovery Model and the Backup Type.
Had the Recovery Model been "Simple" or "Bulk-Logged", the story would have ended there itself. Moreover, at this point, we are still not sure if the Database Recovery Model had been changed; we were trying our luck. Had it been changed, that would have been the end of the story as well. Also, the Backup Type was "Full", so, we were good to go with this backup.
We now stopped the SQL Server instance and renamed the existing log file (the LDF file). We had actually planned to drop this database, and we did not want the LDF file to get deleted.
Now, we started the SQL Server and dropped the database. Drop completed successfully, leaving behind the LDF file.
At this point, we created a new database, and pointed the LDF file of the new database to the location where the old LDF file existed. This was to save us the task of copying the old LDF file over to the new location; the old LDF file was about 300 GB in size.
We now stopped the SQL Server, and replaced the LDF file of the newly created database by the old LDF file.
We started the SQL Server, and, as expected, the database was in Suspect Mode.
We now, issued the following command:
BACKUP LOG DatabaseName
TO DISK = 'Full path to TRN Backup file'
WITH NO_TRUNCATE
This command completed successfully and we had a Tail Backup of the Log File. I would like to mention here, that we had a point-of-failure here. Had the Recovery Model of the database been changed after the Full Backup, this command would have failed.
Now, we were all set to restore the database. So, we proceeded with restoring the Full Backup. We issued the command:
RESTORE DATABASE NewDatabaseName
FROM DISK = Full path to the FULL Backup'
WITH
MOVE 'Data File Name' TO 'Full path to MDF File location',
MOVE 'Log File Name' TO 'Full path to LDF File location',
NORECOVERY
The Full Backup was restored and the database was in Recovering Mode.
Next step was to restore the Log Backup. We issued the command:
RESTORE LOG DatabaseName
FROM DISK = 'Full path to LDF File location'
WITH RECOVERY
The backup restored successfully, and the database was back up online!!
Here, again, we had a point of failure. If the Full Backup that we had restored not been the Last Full Backup; meaning, had there been another Full Backup after the backup set we had restored, the restoration of the Tail Log Backup would have failed!
However, we WERE lucky!!!
вторник, 15 сентября 2009 г.
ASP.NET-полезное (SQL Lite)
http://sqlite.phxsoftware.com/
System.Data.SQLite is the original SQLite database engine and a complete ADO.NET 2.0/3.5 provider all rolled into a single mixed mode assembly. It is a complete drop-in replacement for the original sqlite3.dll (you can even rename it to sqlite3.dll if you're using it natively).
А так же
http://www.rusdoc.ru/articles/ispolzovanie_sqlite_v_net_prilozhenijax/18467/
System.Data.SQLite is the original SQLite database engine and a complete ADO.NET 2.0/3.5 provider all rolled into a single mixed mode assembly. It is a complete drop-in replacement for the original sqlite3.dll (you can even rename it to sqlite3.dll if you're using it natively).
А так же
http://www.rusdoc.ru/articles/ispolzovanie_sqlite_v_net_prilozhenijax/18467/
Подписаться на:
Сообщения (Atom)