Разъяснение предыдущих ответов...
1) Добавляют, новый файл к Вашему проекту (Добавьте-> Новый Объект-> Файл Конфигурации приложения)
2), новый файл конфигурации появится в Проводнике Решения как Приложение. Конфигурация.
3) Добавляют, что Ваши настройки в этот файл с помощью следующего в качестве шаблона
<configuration>
<appSettings>
<add key="setting1" value="key"/>
</appSettings>
<connectionStrings>
<add name="prod" connectionString="YourConnectionString"/>
</connectionStrings>
</configuration>
4) Получают их как это:
private void Form1_Load(object sender, EventArgs e)
{
string setting = ConfigurationManager.AppSettings["setting1"];
string conn = ConfigurationManager.ConnectionStrings["prod"].ConnectionString;
}
5), Когда создано, Ваша выходная папка будет содержать файл, названный < assemblyname> .exe.config Это будет копией Приложения. Файл конфигурации. Никакая дальнейшая работа не должна должна быть быть сделана разработчиком для создания этого файла.
Спасибо, ребята, за ваши ответы. Получение ошибки из сообщения о повторном вызове исключения - это то, что я уже сделал.
@gbn Мне также понравился ответ gbn, но я буду придерживаться этого ответа, так как он работает лучше всего, и я разместив его здесь в надежде, что он также будет полезен другим.
Ответ - использование транзакций в приложении. Если я не t поймать исключение в хранимой процедуре, я получу исходный номер в объекте SqlException. После обнаружения исходного исключения в приложении я пишу следующий код
transaction.Rollback();
В противном случае:
transaction.Commit();
Это намного проще, чем я ожидал вначале!
http://msdn.microsoft.com/en-us/library/system .data.sqlclient.sqltransaction.aspx
Я использую следующий шаблон:
CreatePROCEDURE [dbo].[MyProcedureName]
@SampleParameter Integer,
[Other Paramaeters here]
As
Set NoCount On
Declare @Err Integer Set @Err = 0
Declare @ErrMsg VarChar(300)
-- ---- Input parameter value validation ------
Set @ErrMsg = ' @SampleParameter ' +
'must be either 1 or 2.'
If @SampleParameter Not In (1, 2) Goto Errhandler
-- ------------------------------------------
Begin Transaction
Set @ErrMsg = 'Failed to insert new record into TableName'
Insert TableName([ColumnList])
Values [ValueList])
Set @Err = @@Error If @Err <> 0 Goto Errhandler
-- ------------------------------------------
Set @ErrMsg = 'Failed to insert new record into Table2Name'
Insert TableName2([ColumnList])
Values [ValueList])
Set @Err = @@Error If @Err <> 0 Goto Errhandler
-- etc. etc..
Commit Transaction
Return 0
/* *************************************************/
/* ******* Exception Handler ***********************/
/* *************************************************/
/* *************************************************/
ErrHandler:
If @@TranCount > 0 RollBack Transaction
-- ------------------------------------
RaisError(@ErrMsg, 16, 1 )
If @Err = 0 Set @Err = -1
Return @Err
You might be able to rethrow it like this:
..
END TRY
BEGIN CATCH
DECLARE @errnum int;
SELECT @errnum = ERROR_NUMBER();
RAISERROR (@errnum, 16, 1);
END CATCH
However, you most likely lose a lost of meaning because of the %s etc placeholders in the sys.messages rows for ERROR_NUMBER()
You could do something like this to include the number and rethrow the original message
..
END TRY
BEGIN CATCH
DECLARE @errnum nchar(5), @errmsg nvarchar(2048);
SELECT
@errnum = RIGHT('00000' + ERROR_NUMBER(), 5),
@errmsg = @errnum + ' ' + ERROR_MESSAGE();
RAISERROR (@errmsg, 16, 1);
END CATCH
The first 5 chars are the original number.
But if you have nested code, then you'll end up with "00123 00456 Error text".
Personally, I only deal with SQL Exception numbers to separate my errors (50000) from Engine errors (eg missing parameters) where my code does not run.
Finally, you could pass it out the return value.
I asked a question on this: SQL Server error handling: exceptions and the database-client contract
Если вы используете BEGIN TRY / BEGIN CATCH в T-SQL, вы теряете исключение, вызванное исходным движком. Вы не должны вручную вызывать системные ошибки, поэтому вы не можете повторно вызвать исходный номер ошибки 2627. Обработка ошибок T-SQL не похожа на обработку ошибок C # / C ++, нет средств для повторного выброса исходной ошибки. исключение. Существует ряд причин, по которым существует это ограничение, но достаточно сказать, что оно существует, и вы не можете его игнорировать.
Однако нет никаких ограничений на повышение собственных кодов ошибок, если они превышают диапазон 50000. Вы регистрируете свои собственные сообщения с помощью sp_addmessage , когда приложение установлено:
exec sp_addmessage 50001, 16, N'A primary key constraint failed: %s';
и в вашем T-SQL вы вызываете новую ошибку:
@error_message = ERROR_MESSAGE();
raiserror(50001, 16, 1, @error_message;
В коде C # вы должны искать номер ошибки 50001 вместо 2627:
foreach(SqlError error in sqlException.Errors)
{
switch (error.Number)
{
case 50001:
// handle PK violation
case 50002:
//
}
}
Я хотел бы ответить попроще, но, к сожалению, так обстоят дела. Обработка исключений T-SQL явно не интегрируется в обработку исключений CLR.
Вот код, который я использую для решения этой проблемы (вызывается из CATCH). Он вставляет исходный номер ошибки в текст сообщения:
CREATE PROCEDURE [dbo].[ErrorRaise]
AS
BEGIN
DECLARE @ErrorMessage NVARCHAR(4000)
DECLARE @ErrorSeverity INT
SET @ErrorMessage = CONVERT(VARCHAR(10), ERROR_NUMBER()) + ':' +
ERROR_MESSAGE()
SET @ErrorSeverity = ERROR_SEVERITY()
RAISERROR (@ErrorMessage, @ErrorSeverity, 1)
END
Затем вы можете проверить SqlException.Message.Contains ("2627:")
, например.