Поле только для чтения в SQL
Может тригер на апдейт повесить, смотреть IF UPDATE ( column ) и при необходимости делать ROLLBACK
значение по умолчанию в ДатаСетах есть DataColumn.DefaultValue Property, и в дизайнере его можно выставить.
но засада в том, что из-за этой колонки нельзя пользовать CommandBuilder 
2. Как это сделать было бы правильно - есть ли переносимые стандартные средства, позволяющие определить дату создания записи в БД? (тогда можно было бы вообще отказаться от колонки с датой создания)зачем тебе дата, которую выдает машинный таймер? а если он собьется или перевод часов случится?
У меня много клиентов.
У каждого на компе может быть установлено какое угодно время, поэтому юзать я хочу серверное время.
Все-таки на сервере пользователь не сможет время поменять и я буду точно уверен, что при сортировке по CreateDate строки в таблицу добавлялись именно в таком порядке.
У каждого на компе может быть установлено какое угодно время, поэтому юзать я хочу серверное время.
Все-таки на сервере пользователь не сможет время поменять и я буду точно уверен, что при сортировке по CreateDate строки в таблицу добавлялись именно в таком порядке.
Ага. А еще туда нельза прописать функцию getdate потому что она имеет смысл только на сервере.
+1 вариант - вставлять данные только через хранимую процедуру
Может лучше на трёхзвенку перейти?
Такой вариант сейчас самый рассматриваемый 
Хотелось бы все-таки пользоваться автогенерацией датасета.
А тут придется мало того, что хранилку писать, а потом при изменеии базы ее поддерживать в актуальном состоянии, так еще и код писать для добавления, изменения, выбора и удаления и его поддерживать.
Автогенерация не для того, чтобы после руками че-то делать...
Я не ленивый, я люблю автоматизацию, потому что при этом ошибок от невнимательности быть не может.
Хотелось бы все-таки пользоваться автогенерацией датасета.
А тут придется мало того, что хранилку писать, а потом при изменеии базы ее поддерживать в актуальном состоянии, так еще и код писать для добавления, изменения, выбора и удаления и его поддерживать.
Автогенерация не для того, чтобы после руками че-то делать...
Я не ленивый, я люблю автоматизацию, потому что при этом ошибок от невнимательности быть не может.
Это што за зверь такой?
Такой вариант сейчас самый рассматриваемый
Хотелось бы все-таки пользоваться автогенерацией датасета.
А тут придется мало того, что хранилку писать, а потом при изменеии базы ее поддерживать в актуальном состоянии, так еще и код писать для добавления, изменения, выбора и удаления и его поддерживать.
Я бы написал свою генерилку типизированных датасетов и хранимых процедур (если их много). А код поддерживать в актуальном состостоянии придется по любому...
То что генерит студия, все ее sql-команд-билдеры и т.д. и т.п. - это полная дребедень... - ну типа все же у нас visual
... Кто-нибудь их использовал в серьезном проекте?
По поводу трехзвенки - тут появляется дополнительный уровень с некоторым набором функций, приложение будет работать с ним, прямого доступа к хранилищу данных нет.
Хотелось бы все-таки пользоваться автогенерацией датасета.
А тут придется мало того, что хранилку писать, а потом при изменеии базы ее поддерживать в актуальном состоянии, так еще и код писать для добавления, изменения, выбора и удаления и его поддерживать.
Я бы написал свою генерилку типизированных датасетов и хранимых процедур (если их много). А код поддерживать в актуальном состостоянии придется по любому...
То что генерит студия, все ее sql-команд-билдеры и т.д. и т.п. - это полная дребедень... - ну типа все же у нас visual
... Кто-нибудь их использовал в серьезном проекте? По поводу трехзвенки - тут появляется дополнительный уровень с некоторым набором функций, приложение будет работать с ним, прямого доступа к хранилищу данных нет.
Все-таки на сервере пользователь не сможет время поменять и я буду точно уверен, что при сортировке по CreateDate строки в таблицу добавлялись именно в таком порядке.В общем случае, если отрабатывают одновременно несколько транзакций время с машиоонного (серверного) таймера не совсем то что нужно. Пусть первая транзакция TA вставила запись A, а вторая транзакция ТВ вставила запись В. В реальном времени запись А может оказаться раньше записи В, но в сериализационном плане транзакция TA может идти после TB. Поэтому, если ты в бизнес-логике будешь затачиваться на реальное время вставки записи А, это будет не совсем корректно.
Ты считаешь себя умнее архитекторов из Microsoft? Или ты будешь писать под каждый проект свою генерилку, учитывая специфику проекта?
Я бы написал свою генерилку типизированных датасетов и хранимых процедур (если их много). А код поддерживать в актуальном состостоянии придется по любому...
нет, не считаю.
писать генерилку свою не было желания. я использую готовый кодесмит, в нем есть нормальный фреймворк для генерации кода, работы с метаданными (по крайней мере для ms sql server) и куча базовых шаблонов. доработка шаблона под каждую задачу - минутное дело
писать генерилку свою не было желания. я использую готовый кодесмит, в нем есть нормальный фреймворк для генерации кода, работы с метаданными (по крайней мере для ms sql server) и куча базовых шаблонов. доработка шаблона под каждую задачу - минутное дело
не понимаю, в чем проблема?
не помню как в MSSQL, но в FB/Oracle что-то вроде такого:
пишешь 2 триггера:
1) before insert
new.CreationTime='NOW' -- пофиг что пришло, перезапишем серверным временем
2) before update
new.CreationTime=old.CreationTime -- пофиг что пришло, перезапишем старым значением
либо
if (new.CreationTime is distinct from old.CreationTime) then
exception 'Fuck you!'
endif
не помню как в MSSQL, но в FB/Oracle что-то вроде такого:
пишешь 2 триггера:
1) before insert
new.CreationTime='NOW' -- пофиг что пришло, перезапишем серверным временем
2) before update
new.CreationTime=old.CreationTime -- пофиг что пришло, перезапишем старым значением
либо
if (new.CreationTime is distinct from old.CreationTime) then
exception 'Fuck you!'
endif
не знаю не знаю, те ORM, которые я смотрел, были не гибкими и не прозрачными. Имхо, это ожидаемо, поскольку коде-генерация это зло, тем самым язык подписывается под тем, что он не удобен для таких задач.
нет, не считаю.
писать генерилку свою не было желания. я использую готовый кодесмит, в нем есть нормальный фреймворк для генерации кода, работы с метаданными (по крайней мере для ms sql server) и куча базовых шаблонов. доработка шаблона под каждую задачу - минутное дело
коде-генерация это зло, тем самым язык подписывается под тем, что он не удобен для таких задач.Кодогенерация - зло, студия использует кодогенерацию при создании типизированных датасетов, следовательно такие датасеты зло и C# используя кодогенерацию подписывается под тем ,что он не удобен для задач доступа к данным. Я правильно рассуждаю?
да, на сегодняшний момент именно так, в C# 3.0 вроде, что намечается хорошее
P.S. сейчас я использую не типизированные датасеты с паттерном адаптер (кажется так он называется)
P.S. сейчас я использую не типизированные датасеты с паттерном адаптер (кажется так он называется)
Я написал две серьезных проги на C# и мне очень нравится Typed Dataset, особенно в Net 2.0, особенно с TableAdapter'ами.
В чем трудность с хранимыми процедурами? И зачем вам CommandBuilder если есть TableAdapter?
Что-то я не втыкаю...
В чем трудность с хранимыми процедурами? И зачем вам CommandBuilder если есть TableAdapter?
Что-то я не втыкаю...
Я написал две серьезных проги на C# и мне очень нравится Typed Datasetтебе разрешили писать серьезные проги на бета-версии?
TableAdapter'ами.со вторым фреймфорком я пока не работал, TableAdapter чем-то принципиально отличается от DataAdapter-а? (при первом просмотре MSDN-а я этого не заметил)
В чем трудность с хранимыми процедурами? И зачем вам CommandBuilder если есть TableAdapter?
С каким кол-вом таблиц ты работал?
Как часто и сколько раз менялись требования?
Как часто и сколько раз менялись требования?
Ну засрали человека...
На самом деле, в .Net 2.0 весьма удобно сделана работа с источниками данных.
И при изменении структуры БД, много переделывать не приходится.
Там довольно грамотный автогенератор кода, который может не перегенеривать весь датасет, а внести только локальные изменения в него в соответствии с изменениями в БД.
И databinding там весьма и весьма удобный и прозрачный.
Короче, меня эта система пока радует.
На самом деле, в .Net 2.0 весьма удобно сделана работа с источниками данных.
И при изменении структуры БД, много переделывать не приходится.
Там довольно грамотный автогенератор кода, который может не перегенеривать весь датасет, а внести только локальные изменения в него в соответствии с изменениями в БД.
И databinding там весьма и весьма удобный и прозрачный.
Короче, меня эта система пока радует.
Там довольно грамотный автогенератор кода, который может не перегенеривать весь датасет, а внести только локальные изменения в него в соответствии с изменениями в БД.что-то я не понял это предложение, какая разница, как там генератор кода работает, сейчас машины быстрые, по любому всё быстро работает. Вопрос в том, что схема датасета дублирует схему БД. Поскольку схема датасета создается в ручную в дизайнере, перетаскиванием таблиц из схемы БД , мы получаем гемор с синхронизацией схемы БД и схемы датасета, т.е. каждый раз нам опять перетаскивать те же таблички и опять расставлять релейшаны.
Да и вообще, иногда хочется подписать что-нибудь свое внутри класса бизнес-сущности, какого хуя они не поддерживают наследование от DataRow?
Видно, что ты этим не пользовался...
Ниче делать вручную не надо.
При синхронизации студия показывает несоответствия БД и датасета.
Надо поставить галочки напротив тех таблиц, которые тебе нужны в датасете.
Если ты чего-то накодил (запросы добавил, например) в другой таблице, код твой не пропадет.
Ниче делать вручную не надо.
При синхронизации студия показывает несоответствия БД и датасета.
Надо поставить галочки напротив тех таблиц, которые тебе нужны в датасете.
Если ты чего-то накодил (запросы добавил, например) в другой таблице, код твой не пропадет.
а?
>> Поскольку схема датасета создается в ручную в дизайнере, перетаскиванием таблиц из схемы БД
Эээ ты чо, чувак? Схема датасета создаётся вижуальником по клику куда-то в контекстное менюшко sqlConnection'а. В 2003, правда, он не умел релейшены проставлять (или мне не удалось просто его заставить возможно, в 2005 это могли поправить.
Более того, продвинутые чуваки рисуют базу в PowerDesigner, который потом прекрасно создаёт схему, в принципе может сразу и датасет, но я не пробовал. Ещё он выдаёт скульскрипт для создания базы. При наличии прямых рук несложно получить скульскрипт, изменяющий базу до новой версии (либо вырезая ненужные куски из скульскрипта создания, либо копипейстом из preview для каждой затронутой таблицы). Не исключено, кстати, что он сам может такой скрипт делать автоматически, не знаю, меня обилие пунктов в его главной менюшке ужасает.
Эээ ты чо, чувак? Схема датасета создаётся вижуальником по клику куда-то в контекстное менюшко sqlConnection'а. В 2003, правда, он не умел релейшены проставлять (или мне не удалось просто его заставить возможно, в 2005 это могли поправить.
Более того, продвинутые чуваки рисуют базу в PowerDesigner, который потом прекрасно создаёт схему, в принципе может сразу и датасет, но я не пробовал. Ещё он выдаёт скульскрипт для создания базы. При наличии прямых рук несложно получить скульскрипт, изменяющий базу до новой версии (либо вырезая ненужные куски из скульскрипта создания, либо копипейстом из preview для каждой затронутой таблицы). Не исключено, кстати, что он сам может такой скрипт делать автоматически, не знаю, меня обилие пунктов в его главной менюшке ужасает.
как ты синхронизируешь изменения в схеме бд с со схемой типизированного датасета. я в vs 2005 ничего подобного найти не могу.
о какой синхронизации с базой ты говоришь? только что проделал, сделал датасет, потом поменял табличку в базе, в датасете ничего не поменялось. И релейшены она из базы не берет
Ниче делать вручную не надо.
При синхронизации студия показывает несоответствия БД и датасета.
Надо поставить галочки напротив тех таблиц, которые тебе нужны в датасете.
Если ты чего-то накодил (запросы добавил, например) в другой таблице, код твой не пропадет.
. Вообще единственное существенное отличие от VS2003 это то, что запросы прикреплены к дизайнеру датасета и генерятся в отдельных классах, а не во внутренних переменных формы, что было не удобно в VS2003.Хм.
Можно схему датасета синхронизировать с БД. Наоборот нельзя.
Мне это не нужно.
Не знаю, зачем нужно тебе...
Можно схему датасета синхронизировать с БД. Наоборот нельзя.
Мне это не нужно.
Не знаю, зачем нужно тебе...
Гм.
У меня все пашет как танк!
Может быть, ты думаешь, что синхронизация будет происходить автоматически? Если да, то нет.
Надо пройтись визардом по датасету еще раз, чтобы добиться его синхронизации с БД.
У меня все пашет как танк!
Может быть, ты думаешь, что синхронизация будет происходить автоматически? Если да, то нет.
Надо пройтись визардом по датасету еще раз, чтобы добиться его синхронизации с БД.
Может быть, ты думаешь, что синхронизация будет происходить автоматически? Если да, то нет.синхронизация в ручную, лол
, сапожник без сапог, т.е. программеры пишут проги для автоматизации бизнес процессов, а сами без автоматизации Не знаю, зачем нужно тебе...ну ломается меня куда то там еще лезть и кликать мышкой, если всего лишь надо добавить столбец к табличке. Поменять имя колонки еще сложнее.
Изменение имени таблицы, изменение ключей, изменение релейшенов, это вообще тушите свет, наверное легче всё заново сделать
. Причем бизнес логика не особо может поменяться, т.е. это только программерские сложности.хотя согласен, конечно, что по сравнению с VS2003, в визуальных средствах есть улучшения: источники данных, и т.д.
прикольно, что можно дописывать свою логику к сгенеренным классам через partial class, но почему то дописанные свойства не видны в DataSources и соответственно через DataBinding они не добавляются в DataGridView
почему свойство My.Zx видно в источниках данных, Test1DataSet.T3Row.Zx не видно ?
Microsoft издевается над разработчиками
и соответственно через DataBinding они не добавляются в DataGridView
partial class Test1DataSet
{
partial class T3DataTable
{
}
partial class T3Row
{
public bool Zx
{
get
{
return false;
}
}
}
}
public class My
{
public bool Zx
{
get
{
return false;
}
}
}
почему свойство My.Zx видно в источниках данных, Test1DataSet.T3Row.Zx не видно
?Microsoft издевается над разработчиками
Оставить комментарий
aleks058
Задача такая.Прогаю под .Net 2.0 и MS SQL 2000.
Почти в каждой таблице есть колонка CreateDate - время создания записи.
Это поле имеет тип datetime, NOT NULL, default value = getdate.
Вопросы:
1. Можно ли совсем запретить запись в эту колонку, чтобы я был уверен, что никто при создании записи не прописал шаловливыми ручками дату создания? Если да, то как? Я нашел только запрещение на Update, на Insert для отдельной колонки права выставить не получается.
2. Как это сделать было бы правильно - есть ли переносимые стандартные средства, позволяющие определить дату создания записи в БД? (тогда можно было бы вообще отказаться от колонки с датой создания)
3. Этот вопрос уже по .Net. Сгенерился у меня автоматически типизированный датасет. Эта колонка нулы запрещает, а понятия "значение по умолчанию", я так понимаю, для датасета не существует. Хочу добавить строку в этот датасет и не могу: нулы запрещены. Приходится писать в этот столбец в датасете фигню типа DateTime.Now, а в InsertCommand выкидывать колонку CreateDate, чтобы база сама дату прописала.