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

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

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

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

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

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

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

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

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

Чудес не бывает. Если все остальные тесты показывают, что канал широкий, то дело:

1. в самом сервере - железо не тянет, а ваш более производительный.
2. в запросе. Надо смотреть план выполнения.

По личному опыту - в 90 случаях из 100 дело в запросе. Это ведь не просто select * from ТолькоОднаМояТаблица?
Вот попробуйте такой. Большую таблицу, и просто выборку всего подряд. Если тормозит - дело в сервере. Если не тормозит - дело в вашем запросе.

Осталось только подумать, как будет при варианте с индексом. :)

Нормально это делается в том числе и так. Вообще in - для набора значений, но никто вас не покроет позором и презрением, если вы там будете всего одну значению иметь. А вот not like - этого не надо.

А заносят данные менеджеры пользуясь прямым доступом к базе или через процедуру? Обычно, если разработчик не мммм... странный чудак, это делается через процедуру. Имеет смысл посмотреть на нее и в ней поменять.

Ну, если уж никак и нужен триггер - да, это возможно, абсолютно ничего сложного нет, так и пишется create trigger ... on [tablename] ... for update, insert в нем проверяете, что обновляется/вставляется поле Phone и делаете вставку-апдейт нужного вам значения. Работы на полчаса, если прочитать хелп по create trigger, неопытному человеку. Лучше делать триггера отдельно для апдейта и инсерта свой.

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

Таблица - это уже массив. Не надо мудрить и писать в массив еще один.

зайди как sa. А сейчас у тебя прав, скорее всего, нет. :) Very easy :)