Перед прочтением статьи, ответьте на следующий вопрос — что будет напечатано, после исполнения следующего кода?

P p = Console.WriteLine; // P объявлен как delegate void P();
foreach (var i in new [] { 1, 2, 3, 4 }) {
  p += () => Console.Write(i);
}
p();

Если вы используете JavaScript, но при этом так до конца и не разобрались, что же это за чудная штука такая — замыкания, и зачем она нужна — эта статья для вас.

Этот пост – отчет по результатам годового изучения платформы Java EE.
Он будет полезен мне своей отчетностью. Может быть пост будет полезен тем читателям хабра, которые задумали учить Джаву.

В первой своей статье, посвящённой конвертерам, я описал способ использование конвертеров в качестве расширения разметки. Продолжая тему конвертеров, хотелось бы рассказать о параметрах конвертера.

Конверторы являются одной из важнейшей особенностью механизма привязки в WPF. Они позволяют управлять тем, как источник привязки будет представлен в UI. В данной статье я покажу, как немного упростить использование конвертеров в XAML коде.

Продолжение по ссылкам: часть II и часть III.

На PDC2010 Хейсберг объявил, что следующая версия C# будет поддерживать примитивы для удобной организации асинхронных вычислений, кроме анонса была представлена CTP версия расширения для студии (скачать), которая позволяет попробовать улучшенное асинхронное программирование уже сейчас.

Улучшение создано, чтобы облегчить комбинацию асинхронных операций, а так же для того, чтобы асинхронных код выглядел максимально приближенно к синхронному. Учитывая, что Silverlight версия .NET Framework содержит только асинхронную модель для работы с сетью, данное улучшение очень уместно.

Не смотря на то, что упрошенное асинхронное программирование является нововведением в C#, сам подход нельзя назвать инновационным, так как реализация async на основе монад есть в Haskell, F# и Nemerle. На самом деле поддержка языком монад позволяет реализовать даже большее, поэтому я был немного удивлен, когда посмотрел презентацию Хейсберга и понял, что в язык был встроен только частный случай.

Что такое большой файл? Ну так чтобы реально большой? В бытность свою я думал, что это файлик на 50-60 тыс строк записей. И оставался я бы в таком неведении до сих пор, но пришлось выполнять один проект, в котором надо было работать с файлами на 600-800 тыс строк. Хождение по мукам — под катом:

Приложение не отвечает?!

Многие из тех, кто программирует WPF-приложения, наверное тысячи раз писали конструкцию вида:

{Binding Items}

Если получение элементов коллекции Items выполняется в основном потоке приложения и занимает некоторое время — мы получаем «мертвый» пользовательский интерфейс. Приложение некоторое время не будет отрисовывать изменения состояния и реагировать на пользовательский ввод.

SqlBulkCopy — это эффективное решение для массовой загрузки данных в таблицы Microsoft SQL Server. Источник данных может быть любой, будь то xml-файл, csv-файл или другая СУБД, например MySQL. Достаточно получить из источника данные в виде объекта DataTable или реализовать интерфейс IDataReader поверх методов доступа к данным.

Вам не придется создавать файлы на диске для дальнейшей их загрузки с помощью утилиты BCP, вам не придется писать код для генерации множественных INSERT запросов. При загрузке данных SqlBulkCopy работает на более низком уровне, позволяя вставлять миллионы записей за максимально короткий срок.

Поврежденная база данных — это, наверное, один из худших ночных кошмаров большинства администраторов баз данных. Результатом повреждения являются простои, вопли менеджеров и всякие другие неприятные штуки.
В этой статье я объясню что нельзя делать с поврежденной базой данных и опишу кое-что из того, что должно быть сделано, некоторые виды повреждений и как их можно исправить.

Как обнаружить, что база данных повреждена

Обычно повреждения превосходно обнаруживаются при попытке доступа к поврежденной странице. Запросы, бэкапы или процедуры реиндексации завершаются ошибками с высокими уровнями серьезности.
Вот пара примеров системных сообщений при обнаружении повреждения БД:

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.

Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

Основная проблема заключается в том, что если проверки целостности базы данных не производятся на постоянной основе, то повреждение может быть обнаружено спустя часы, дни и даже месяцы, после того, как оно образовалось, в тот момент, когда уже сложно будет что-то исправить.