Артём Каретников

То, что у вас делает запрос, означает следующее:

Для поля STAMP
возьми значение из поля [NotifyManagerTimestamp]
Поэтому и ошибка. Вам о ней и пишут: поле такое не найдено. Если вы хотите использовать переменную, то это вот так: @NotifyManagerTimestamp

Если полная модель восстановления - то все можно. Надо как можно быстрей сделать бекап лога в восемь разных мест. Откуда уверенность, что ldf не поврежден? Он лежал на другом диске? Как повредился mdf?
Размер базы какой, что именно нужно вытянуть, ее всю или ограничиться какими-то таблицами? Мало информации, стоит изложить поподробней.

Я лично сторонник того, что в процедуры запросы надо выносить всегда. Т.е. вообще и абсолютно. И тут всего два аргумента, но они весьма весомы, если подумаете:

1. Юзер не имеет прямого доступа к таблицам. В случае запросов в коде - придется что-то с этим решать, да? Либо давать права каждому, либо придумывать некий общий логин, но тогда не отследить просто, кто и что в базе поменял.
2. Прекомпиляция запросов, работа со статистикой. Если запросы делать не в процедурах - то перед выполнением они будут компилироваться - и так каждый раз. Банальности в процедурах - не беда.

Ну и последнее. Внезапно возникает решение переделать код на другой язык/систему. Если вся серверная логика, как положено, на сервере - переделок будет значительно меньше, чем если лазить по всему коду и переписывать это еще раз в другую систему.

C юзерами и правами - вообще самое простое из этого. Читайте в сети про sp_hexadecimal and sp_help_revlogin. Создаются две процедуры, потом один скрипт, который нужно запустить на новом сервере - и пользователи с паролями перенесены.

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

Крайне рекомедую использовать именно процедуры везде, где это возможно. Для разработчика GUI - это черный ящик, он знает параметры вызова и возвращаемые значения, а что внутри - нет. Для юзера аналогично.
Она прекомпилится, внутри нее можно сделать любую красоту... Сторки - это наше всё.

Уверенность есть, что виртуальное окружение запущено? Очень похоже на то, что нет.

Она ведь не сама по себе появляется, правда? Т.е вы как минимум открываете форму
Что показывает эта форма в дизайнтайме? Какие ссылки видны в references?

Меня вообще тоже интересует, особенно вопросы цен. Какие-то дичайшие просто расклады - приложение из одной-двух страниц - по сто долларов за каждую страницу... И это еще без дизайна, с дизайном глаза совсем на лоб. Откуда такие цены, почему? Чем писать на мобилы сложней, чем на десктоп?

Доброго. Рыбу я не дам, дам удочку.
Обновление одного - это событие. Alter Update
Соответственно, в это событие следует написать присвоение/обновление данных для второго элемента.
Данные селектом получить можете? Вот и присваивайте этот набор записей текстовому полю.

Могут продать домен очень дешево. Но вот его продление - будет стоить уже совсем других денег.
Количество и качество дополнительных услуг разнятся. Например, где-то есть круглосуточная поддержка, где нет.
Где-то есть услуга скрытия контактных данных, где-то нет. И так далее.

В общем и целом, лучше американские и крупные, типа godaddy.com

Не начинать с реляционной алгебры и теории множеств.

Прочитать толковый учебник тип Грубера, "понимание sql" и просто написать себе самому - ну, хоть телефонный справочник. Сделать поначалу одну таблицу, вставку, обновление, удаление, выборку. Потом подумать - какие операции являются лишними, какие поля задублированы, как их можно было бы вынести в другие таблицы - вот это будет оптимизация и нормализация.

Результаты раздумий выложить толковому человеку с просьбой помочь - и всё. А вот эта вся фундаментализация прямо сразу - вернейший способ отбить все понимание сразу и навсегда.

Начинать крайне рекомендовал бы по Груберу, "понимание SQL"
Простая, с хорошими примерами - но только надо брать бумажную, вычитанную, в сети гуляет версия с кучей опечаток.

Доброго. Легко отвечу, что за чем выполняется и вообще научу sql. Заодно ткну в ошибки, как минимум одна потенциальная тут есть. Будет желание - скайп и емейл мой тут указаны, договоримся.
А бесплатно рассказывать, что как и почему - как видите, охотников мало тратить свое время просто так.

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

Доброго. В ссылках искать ошибку. Куда ссылки ведут, на локальный сайт или в пространство? Вообще, денвер довольно подробно описывает все в своем хелпе.