Форум: "Базы";
Текущий архив: 2006.08.13;
Скачать: [xml.tar.bz2];
ВнизИспользуя ЗАБОЙ, полю присваивается NULL, а хотелось бы НОЛЬ Найти похожие ветки
← →
q-q (2006-06-06 10:07) [0]При удалении цифры используется Забой => Полю присваивается NULL, а хотелось бы НОЛЬ. Устанавливать NOT NULL полю не хотелось бы (удалять инф-цию удобней Забоем, а не НУЛЕМ). Триггер на update (if f.new is null then f.new=0) по каждому числовому полю тоже нехорошо.
Подскажите, как решить оптимальнее на уровне базы.
← →
Ega23 © (2006-06-06 10:10) [1]Что такое "Забой"???????????
← →
q-q (2006-06-06 10:12) [2]"ЗАБОЙ" = Backspase | Delete
← →
Сергей М. © (2006-06-06 10:15) [3]на стороне клиента в обработчике TDataSet.OnBeforePost() пройтись в цикле по полям дейтасета, для каждого поля типа TIntegerField проверить условие IsNull(Value) и если Истина, то тут же присвоить Value = 0
← →
q-q (2006-06-06 10:16) [4]А на уровне базы
← →
Ega23 © (2006-06-06 10:19) [5]
> А на уровне базы
А где ты видел Backspase | Delete на уровне базы???
← →
Polevi © (2006-06-06 10:20) [6]триггер
← →
Сергей М. © (2006-06-06 10:21) [7]
> q-q (06.06.06 10:16) [4]
>
> А на уровне базы
Это и есть "на уровне базы".
Если же речь идет о стороне сервера, то без явного перебора полей в триггере не обойтись.
Впрочем, в FB можно выкрутиться с пом. EXECUTE STATEMENT и прямым обращением к сист.таблицам, но решение не будет совместимо с IB
← →
q-q (2006-06-06 10:24) [8]Хотелось бы при присваивании полю значения NULL, чтобы оно становилось НУЛЕМ. История про ЗАБОЙ рассказана только для пояснения ситуации, почему такая необходимость возникла.
← →
Johnmen © (2006-06-06 10:29) [9]Объявить поле с NOT NULL DEFAULT 0
← →
Sergey13 © (2006-06-06 10:29) [10]2[8] q-q (06.06.06 10:24)
Вошебства не бывает. "Триггер на update (if f.new is null then f.new=0)" нормальный и самый правильный выход.
← →
q-q (2006-06-06 10:38) [11]>Johnmen © (06.06.06 10:29) [9]
>Объявить поле с NOT NULL DEFAULT 0
Тогда придется удалять инф-цию обнулением поля
to Sergey13
Числовых полей - много, и их число увеличивается. Для каждого создавать триггер - монотонная работа, а точно "Вошебства не бывает" ?
← →
Сергей М. © (2006-06-06 10:40) [12]
> Johnmen © (06.06.06 10:29) [9]
DEFAULT, afair, используется только при вставке.
← →
Sergey13 © (2006-06-06 10:44) [13]2[11] q-q (06.06.06 10:38)
>Числовых полей - много, и их число увеличивается.
Наверное спроектировано не очень хорошо. Симптом известный. 8-)
>Для каждого создавать триггер - монотонная работа, а точно "Вошебства не бывает" ?
Не всякая работа творчество. Встречается и монотонная. А кому щас легко? 8-)
← →
Johnmen © (2006-06-06 10:56) [14]
> Сергей М. © (06.06.06 10:40) [12]
Конечно.
Так у автора апдейт.... Тогда уже сказали - триггеры.
← →
Сергей М. © (2006-06-06 11:07) [15]
> Johnmen © (06.06.06 10:56) [14]
Если у автора, как он утверждает, таких полей вагон и тележка, решение с триггером может привести в тупик - размер кода триггера, как известно, лимитирован.
← →
q-q (2006-06-06 11:26) [16]>Sergey13 © (06.06.06 10:44) [13]
> >Числовых полей - много, и их число увеличивается.
>Наверное спроектировано не очень хорошо. Симптом известный. 8-)
Допустим, сегодня я ввел километраж на утро и километраж на вечер, а завтра воткнул бортовые компьютеры (БК). Завтра новые параметры - литров бензина на утро и вечер. Вчера, когда приектировал, БК еще не были изобретены. Причем тут "спроектировано не очень хорошо".
← →
Ega23 © (2006-06-06 11:30) [17]
> Допустим, сегодня я ввел километраж на утро и километраж
> на вечер, а завтра воткнул бортовые компьютеры (БК). Завтра
> новые параметры - литров бензина на утро и вечер. Вчера,
> когда приектировал, БК еще не были изобретены. Причем тут
> "спроектировано не очень хорошо".
Если бы было спроектировано хорошо, то твои БК воткнулись бы совершенно без проблем.
Расширять таблицу надо очень аккуратно. А то видал я таблицы по 50 полей, причём одно и то же поле для разных записей трактуется по-разному.
← →
Sergey13 © (2006-06-06 11:31) [18]2[16] q-q (06.06.06 11:26)
>Причем тут "спроектировано не очень хорошо".
При том, что много и постоянно растет их количество. 8-)
И твои утренние и вечерние километраж и литры наглядно демонстрируют мою догадку. 8-)
← →
Johnmen © (2006-06-06 11:33) [19]
> Сергей М. © (06.06.06 11:07) [15]
Это ж сколько д.б. полей, чтобы выйти за 48К (причём компилированного кода)??? :)
Если их действительно так много, то это проблемы консерватории...:)))
← →
Сергей М. © (2006-06-06 11:36) [20]
> Причем тут "спроектировано не очень хорошо".
Когда число атрибутов, характеризующих объект, заранее не известно (может варьироваться), атрибуты эти следует описывать и размещать в подчиненной таблице, каждая запись которой будет содержать один атрибут одного объекта. При этом добавление/модификация/удаление атрибута сводится к добавлению/модификации/удалению записи в этой таблице, а не к реструктуризации БД и переделке кода на сторонах клиента и/или сервера.
← →
q-q (2006-06-06 11:41) [21]> Когда число атрибутов, характеризующих объект, заранее не известно
Заранее было ВСЁ! известно.
> следует описывать и размещать в подчиненной таблице
А если отображать и работать надо со строкой
← →
q-q (2006-06-06 11:43) [22]Т. е. с табличным представлением данных
← →
Sergey13 © (2006-06-06 11:45) [23]2[21] q-q (06.06.06 11:41)
> Заранее было ВСЁ! известно.
Не надо нервничать. НИКОГДА заранее ВСЕ! не известно. 8-)
>Т. е. с табличным представлением данных
Для этого существует язык SQL.
← →
Сергей М. © (2006-06-06 11:46) [24]
> Johnmen © (06.06.06 11:33) [19]
Ну мало ли что там еще у автора в триггере будет твориться, кроме упомянутых проверок-присвоений)..
Впрочем, встречаются и такие "клинические случаи", когда народ умудряется достичь это лимита ..
← →
Сергей М. © (2006-06-06 11:50) [25]
> q-q (06.06.06 11:41) [21]
> Вчера, когда приектировал, БК еще не были изобретены
> Заранее было ВСЁ! известно
Ты сам себе противоречишь, заметь !
Мол, БК еще и в помине нет, но мне они уже известны ..
> с табличным представлением данных
Заметь - представлением ! А не хранением ...
Хранение и представление - разные вещи.
← →
q-q (2006-06-06 11:56) [26]>Sergey13 © (06.06.06 11:45) [23]
>Не надо нервничать. НИКОГДА заранее ВСЕ! не известно. 8-)
Параметры километраж на утро и вечер являются неотъемлимой частью путевого листа в сознании всех логистов мира, и закладывать сюда вероятность появления других аттрибутов кажется некорректным
>Для этого существует язык SQL.
Ну-ка, ну-ка. Как с помощью SQL вытащить записи подчинненной таблицы в строку главной
← →
ЮЮ © (2006-06-06 12:00) [27]>сегодня я ввел километраж на утро и километраж на вечер
А про полдень и полночь забыл? Разве Километраж - это атрибут какого-то объекта, дабы было два поля "километраж на утро" и "километраж на вечер".
Это его динамечески изменяющееся свойство, а раз динамика, значит, что-то типа:
Километрах (
Обект,
ДатаВремяИзмерения,
Величина
)
← →
Ega23 © (2006-06-06 12:01) [28]
> Ну-ка, ну-ка. Как с помощью SQL вытащить записи подчинненной
> таблицы в строку главной
1. А нафига?
2. Есть такая штука - join.
← →
Sergey13 © (2006-06-06 12:03) [29]2[26] q-q (06.06.06 11:56)
>Параметры километраж на утро и вечер являются неотъемлимой частью путевого листа в сознании всех логистов мира
Так ты логист?!!! Тогда понятно. Логисту простительно вводить в таблицу авто атрибуты ежедневного километража. 8-)
>Ну-ка, ну-ка.
Не "нукай" - не запряг еще.
>Как с помощью SQL вытащить записи подчинненной таблицы в строку главной
Надо соединить ("сджоинить") главную и подчиненную таблицы. Это азы SQL. То, для чего он и предназначен.
← →
ЮЮ © (2006-06-06 12:03) [30]
> Параметры километраж на утро и вечер являются неотъемлимой
> частью путевого листа в сознании всех логистов мира,
Даже если экспедитор работает в ночную смену? Сознание лрогистов при этом не переворачивается? :)
← →
q-q (2006-06-06 12:05) [31]>Ega23 © (06.06.06 12:01) [28]
>> Ну-ка, ну-ка. Как с помощью SQL вытащить записи подчинненной
>> таблицы в строку главной
>1. А нафига?
>2. Есть такая штука - join.
Для адыкватного восприятия действительности
← →
Сергей М. © (2006-06-06 12:06) [32]
> q-q (06.06.06 11:56) [26]
> Как с помощью SQL вытащить записи подчинненной таблицы в
> строку главной
Не надо туда ничего "вытаскивать", не для того главная таблица предназначена при такой структуре БД.
← →
Ega23 © (2006-06-06 12:07) [33]
> Для адыкватного восприятия действительности
Для этого обычно Master-Detail связку организовавают. В данном случае.
← →
q-q (2006-06-06 12:08) [34]> ЮЮ © (06.06.06 12:03) [30]
> Даже если экспедитор работает в ночную смену? Сознание лрогистов
> при этом не переворачивается? :)
Это со скрипом еще проходит, вот когда счетчик начнет новый круг - вот это да.
← →
ЮЮ © (2006-06-06 12:10) [35]
> Допустим, сегодня я ввел километраж на утро и километраж
> на вечер, а завтра воткнул бортовые компьютеры (БК).
Если завтра бортывые компьютеры станут неотъемлимой
частью путевого листа, что станут делать логисты всего мира ?
← →
Sergey13 © (2006-06-06 12:11) [36]2[34] q-q (06.06.06 12:08)
А логистов всего мира не интересует вчерашний утренний километраж? Не говоря уж о среднемесячном литраже.
← →
ЮЮ © (2006-06-06 12:17) [37]
> Sergey13 © (06.06.06 12:11) [36]
Так они же путевые листы не выбрасывают, надеюсь.
Только откуда у автора проблемы с нулями в озвученных атрибутах. Водители спидометры каждый день на 00000 скручивают?
← →
q-q (2006-06-06 12:30) [38]>ЮЮ © (06.06.06 12:17) [37]
>Только откуда у автора проблемы с нулями в озвученных атрибутах. ?>Водители спидометры каждый день на 00000 скручивают
Пример с водителями взялся из воздуха на фразу:
>Sergey13 © (06.06.06 10:44) [13]
>2[11] q-q (06.06.06 10:38)
>>Числовых полей - много, и их число увеличивается.
>Наверное спроектировано не очень хорошо. Симптом известный. 8-)
и к сабдж никакого отношения не имеет
← →
Сергей М. © (2006-06-06 12:36) [39]
> q-q (06.06.06 12:30) [38]
> к сабдж никакого отношения не имеет
Еще как имеет !
При грамотной организации структуры БД проблема по сабжу отпадает сама собой.
← →
Sergey13 © (2006-06-06 12:36) [40]2[38] q-q (06.06.06 12:30)
>Пример с водителями взялся из воздуха на фразу:
Ну так не все воздушные катаклизмы достойны опубликования. 8-)))))))))))))))
← →
ЮЮ © (2006-06-06 12:38) [41]Ну тогда бы по сабжу рассказал, что это за поля и почему в таблице они должны быть нулевыми, в то время как пользователю удобнее их видеть NULLевыми. Нолики-то зачем? nvl(или как она у вас в FB зовется) в конце концов есть
← →
q-q (2006-06-06 12:44) [42]Пользователу не объяснишь, что числа надо обнулять НУЛИКОМ, они пользуются ЗАБОЕМ. В базу попадает NULL. Запрос суммирования с этой записью возвращает NULL.
← →
unknown © (2006-06-06 12:46) [43]
> ЮЮ © (06.06.06 12:38) [41]
> nvl(или как она у вас в FB зовется)
coalesce
И, все-таки непонятно, почему > Числовых полей - много, и их число увеличивается
← →
Ega23 © (2006-06-06 12:46) [44]
> Пользователу не объяснишь, что числа надо обнулять НУЛИКОМ,
> они пользуются ЗАБОЕМ. В базу попадает NULL. Запрос суммирования
> с этой записью возвращает NULL.
>
Редактировать данные в DBGrid-е и сразу шарашить их в базу - плохой тон.
← →
Sergey13 © (2006-06-06 12:47) [45]2[42] q-q (06.06.06 12:44)
А ты им и не объясняй. Ты программу соответственно напиши.
← →
unknown © (2006-06-06 12:48) [46]
> q-q (06.06.06 12:44) [42]
> Пользователу не объяснишь, что числа надо обнулять НУЛИКОМ
Не надо ничего пользователю объяснять. См. [9] - значение поля по умолчанию
будет = 0. И никаких null-ов.
← →
Sergey13 © (2006-06-06 12:48) [47]2[44] Ega23 © (06.06.06 12:46)
Плохой тон - писать неправильно работающие программы. Все остальное - индивидуальный стиль программирования. 8-)
← →
Сергей М. © (2006-06-06 12:50) [48]
> q-q (06.06.06 12:44) [42]
Тебе чем BeforePost не угодило ?
Зачем (особенно при такой структуре БД) наживать себе геморрой с триггерами, если вся твоя из пальца высосанная проблема до смешного просто решается прямо на стороне клиента ?
← →
Ega23 © (2006-06-06 12:51) [49]
> Плохой тон - писать неправильно работающие программы. Все
> остальное - индивидуальный стиль программирования. 8-)
Согласен. Но если бы люди не пользовали эту дурацкую связку TTable - TDBGrid, то, согласись, таких вопросов бы не возникало.
Ну уж больно всё глючно получается...
← →
Ega23 © (2006-06-06 12:52) [50]
> Пользователу не объяснишь, что числа надо обнулять НУЛИКОМ,
> они пользуются ЗАБОЕМ. В базу попадает NULL. Запрос суммирования
> с этой записью возвращает NULL.
>
А IsNull использовать в запросе религия не позволяет?
← →
saxon (2006-06-06 12:54) [51]Вот так "ЗАБОЙ" :)
← →
Sergey13 © (2006-06-06 12:55) [52]2 [49] Ega23 © (06.06.06 12:51)
Задачи разные бывают. Иногда "TTable - TDBGrid" вполне себя оправдывает. Нпример всевозможные БД Вьюеры/Эдиторы работают именно так. И ничего - люди пользуются.
← →
Ega23 © (2006-06-06 12:57) [53]
> Задачи разные бывают. Иногда "TTable - TDBGrid" вполне себя
> оправдывает. Нпример всевозможные БД Вьюеры/Эдиторы работают
> именно так. И ничего - люди пользуются.
Дуракозащиту очень тяжело ставить, согласись...
← →
q-q (2006-06-06 12:58) [54]> Ega23 © (06.06.06 12:51) [49]
> > Плохой тон - писать неправильно работающие программы.
> Все
> > остальное - индивидуальный стиль программирования. 8-)
> Согласен. Но если бы люди не пользовали эту дурацкую связку
> TTable - TDBGrid, то, согласись, таких вопросов бы не возникало.
Табличные данные надо и представлять, и редактировать в табличной форме, вне завсимости от степени дурноты тона
← →
Ega23 © (2006-06-06 13:00) [55]
> Табличные данные надо и представлять, и редактировать в
> табличной форме, вне завсимости от степени дурноты тона
Вот оно как, оказывается! 7 лет писал клиенты под БД, а таких прописных истин - не знал.
И заказчики, видимо, сплошные идиоты попадались, раз мне таких замечаний не делали.
Вот спасибо, открыл глаза на жизнь!
← →
q-q (2006-06-06 13:02) [56]>Ega23 © (06.06.06 13:00) [55]
>> Табличные данные надо и представлять, и редактировать в
>> табличной форме, вне завсимости от степени дурноты тона
>Вот оно как, оказывается! 7 лет писал клиенты под БД, а таких прописных >истин - не знал.
Зачем людей мучать
← →
Ega23 © (2006-06-06 13:04) [57]
> Зачем людей мучать
Видишь-ли. Судя по данной ветке, людей мучаешь как раз ты. А попутно - сам мучаешься.
Что мешает сделать модальную форму с соответствующими контролами и показывать её на редактирование и изменение данных?
← →
Sergey13 © (2006-06-06 13:06) [58]2[53] Ega23 © (06.06.06 12:57)
> Дуракозащиту очень тяжело ставить, согласись...
Не соглашусь. Но мы уходим от "забойной" темы. 8-)
[56] q-q (06.06.06 13:02)
>Зачем людей мучать
Вот-вот. Приглашай программиста - он все и сделает для удовлетвореня логистов. 8-)
ЗЫ: надо же какой упорный попался! 8-)
← →
q-q (2006-06-06 13:07) [59]А если тебе надо забить >500 позиций как можно быстрее (<2 мин)
← →
ЮЮ © (2006-06-06 13:10) [60]А вот здесь я на стороне q-q.
Правда чтобы отого достичь, к сожалению, DBGrida, да и DataSeta, недостаточно.
>Ega23 © (06.06.06 13:00) [55]
Глянь
http://orpo.msun.ru/files/projects/up.pdf (на стр.4-5). Как, по твоему, "правильнее" и удобнее для пользователя редактировать таблицу, где строки и столбцы - объекты двух разных таблиц, а ячейки - объекты из таюлицы кросс-связей.
Автору. Только у меня это не поля, а объекты(записи), которые либо есть либо нет
← →
ЮЮ © (2006-06-06 13:11) [61][60] - это к [54] vs [55]
← →
Sergey13 © (2006-06-06 13:12) [62]2[59] q-q (06.06.06 13:07)
>А если тебе надо забить >500 позиций как можно быстрее (<2 мин)
Приведи хоть один жизненный пример с 500-ми позиций за <2 мин.
← →
Сергей М. © (2006-06-06 13:12) [63]
> если тебе надо забить >500 позиций как можно быстрее (<2
> мин)
>
На то есть табличные процессоры а-ля Excel и логика импорта.
← →
Ega23 © (2006-06-06 13:13) [64]
> Не соглашусь. Но мы уходим от "забойной" темы. 8-)
Так. Серёг, мы с тобой уже, наверное, раз 20-й на этот счёт схлёстываемся.
Может, тогда, объяснишь мне приватно, как лучше с такой связкой работать? Я несколько раз пытался постичь дао этого дела, но не преуспел.
← →
Ega23 © (2006-06-06 13:14) [65]
> Правда чтобы отого достичь, к сожалению, DBGrida, да и DataSeta,
> недостаточно.
Ну как минимум в ClientDataSet данные писать. А уж потом пытаться базу обновить...
← →
Sergey13 © (2006-06-06 13:16) [66]2[64] Ega23 © (06.06.06 13:13)
Легко. BeforePost дает полный контороль над записью на клиенте. Тригер дает полный контроль на сервере. Полнота контроля никак не зависит от модальности формы редактирования и вида представления информации. ИМХО так.
← →
q-q (2006-06-06 13:42) [67]>>Сергей М. © (06.06.06 13:12) [63]
>> если тебе надо забить >500 позиций как можно быстрее (<2 мин)
>На то есть табличные процессоры а-ля Excel и логика импорта.
%-)))
← →
q-q (2006-06-06 13:48) [68]>Sergey13 © (06.06.06 13:12) [62]
>>А если тебе надо забить >500 позиций как можно быстрее (<2 мин)
>Приведи хоть один жизненный пример с 500-ми позиций за <2 мин.
Забить ревизионную картонку по складу (бывает 5000 поз)
← →
Сергей М. © (2006-06-06 13:51) [69]
> q-q (06.06.06 13:42) [67]
!!!
← →
Sergey13 © (2006-06-06 13:51) [70]2[68] q-q (06.06.06 13:48)
>Забить ревизионную картонку по складу (бывает 5000 поз)
За <20 минут (500/2=5000/20)? Не смешите мои тапочки. 8-)
← →
Ega23 © (2006-06-06 13:54) [71]
> Забить ревизионную картонку по складу (бывает 5000 поз)
- Скажите, а вы можете печатать со скоростью 1000 символов в минуту?
- Конечно могу! Только такая %№;ня получается!
← →
unknown © (2006-06-06 14:00) [72]
> q-q (06.06.06 13:48) [68]
Офигеть %)
У меня операторы максимум 2к записей в день успевают каждый.
Полей ввода порядка 10-ти.
А у вас там киборги наверное сидят %))
← →
q-q (2006-06-06 14:18) [73]полей ввода - 3
вводятся только цифры на правой клаве
500 позиций вводатся за 2 мин
таких картонок 20 каждый день
всего времени не больше 1 ч
просто работа
← →
Sergey13 © (2006-06-06 14:23) [74]2[73] q-q (06.06.06 14:18)
Забойная работа! 8-)
Так в чем ты хочешь всех убедить то? А то я уже запутался. 8-)
← →
q-q (2006-06-06 14:25) [75]ВСЕ, СДАЮСЬ
← →
Johnmen © (2006-06-06 14:26) [76]Т.е. 500*3/120=12.5 значений(да хоть и цифр) в секунду.
Это художественный свист...:)
← →
Danilka © (2006-06-06 14:38) [77][76] Johnmen © (06.06.06 14:26)
Нифига.
Вот-так более верно, и то в реале все будет хуже:
500 строк * (3 колонки * 3 знака в каждой колонке + 3 нажатия enter в каждой колонке для окончания ввода) / 120 секунд = 50 ударов по клавиатуре в секунду.
хотел-бы я на это посмотреть.
← →
Sergey13 © (2006-06-06 14:43) [78]Хорош добивать то. Он же сдался. Лежачего не бьют. 8-))))))))))))
← →
Ega23 © (2006-06-06 14:44) [79]
> Хорош добивать то. Он же сдался. Лежачего не бьют. 8-))))))))))))
Как говорил сенсэй: "Лежачий - не тот, кто упал, а тот, кто встать не может..."
← →
ANB © (2006-06-06 15:15) [80]
> q-q (06.06.06 14:18) [73]
> полей ввода - 3
> вводятся только цифры на правой клаве
> 500 позиций вводатся за 2 мин
> таких картонок 20 каждый день
> всего времени не больше 1 ч
> просто работа
И она намного быстрее делается именно на модальной форме. Более того, пользователь будет меньше путаться, и обращать внимание на то, переключился у него фокус на новую ячейку или нет. И привычные кнопки - ОК и Отмена, вместо непонятных кнопок в навигаторе и тулбаре.
← →
q-q (2006-06-06 15:18) [81]Я сдался на счет того, что вопросы здесь задавать бесполезно!
На счет скорости ввода, если список на экране совпадает со списком с которого забивается, 2 мин на 500 поз - это нормально. Когда приходит новый оператор, он тратит по 15-20 мин, но через месяц работы скорость вырастает 2-5 мин
Всего хорошего
← →
Ega23 © (2006-06-06 15:19) [82]
> Я сдался на счет того, что вопросы здесь задавать бесполезно!
Отнюдь. Тебе ответили. И не один раз.
← →
Sergey13 © (2006-06-06 15:23) [83]2[79] Ega23 © (06.06.06 14:44)
Прав был сэнсей. 8-)
← →
Danilka © (2006-06-06 16:10) [84][81] q-q (06.06.06 15:18)
> На счет скорости ввода, если список на экране совпадает
> со списком с которого забивается, 2 мин на 500 поз - это
> нормально. Когда приходит новый оператор, он тратит по 15-20
> мин, но через месяц работы скорость вырастает 2-5 мин
Немного поподробнее можно?
То-есть, список уже есть в компютере и на экране, осталось его открячить?
Ну, тогда может быть.
Однако набивать что угодно, хотя бы только одну одинаковую цифру, со скоростью 50 знаков в секунду невозможно. Хотя, если одну руку положить на клавиатуру, а вторую в розетку сунуть...
← →
Johnmen © (2006-06-06 16:19) [85]
> Danilka © (06.06.06 16:10) [84]
> Хотя, если одну руку положить на клавиатуру, а вторую в
> розетку сунуть...
Это уже 100 знаков в секунду...
← →
ANB © (2006-06-06 17:51) [86]
> Это уже 100 знаков в секунду...
50 Герц вроде как в розетке . . .
← →
Johnmen © (2006-06-06 17:57) [87]Герцов 50, а пиков 100 :)
← →
ANB © (2006-06-06 18:07) [88]Пик вниз - палец вниз, пик вверх - палец вверх. 2 пика = одно нажатие. Таки 50 раз в секунду.
← →
Desdechado © (2006-06-06 20:33) [89]null
ноль
сканеры с распознавателями на что придумали?
← →
Alex_A_V (2006-06-07 01:53) [90]q-q, тебе же еще в 3 посте ответили.
можно вообще процедурку сделать которая в цикле перебирает все поля и если поле соответсвующего типа и имеет значение NULL, то ему присваивается 0.
Потом для каждого датасета в событие BeforePost вставить по одной строчке с вызовом процедуры, куда уж проще то.
Зачем заморачиваться и делать это на стороне сервера...
Страницы: 1 2 3 вся ветка
Форум: "Базы";
Текущий архив: 2006.08.13;
Скачать: [xml.tar.bz2];
Память: 0.69 MB
Время: 0.045 c