Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
кучка @@identity и что с ними делать?
|
|||
|---|---|---|---|
|
#18+
Хм... интересно что народ посоветует со следующей ситуацией. В базе на всех таблицах имеются identity столбцы. Проблема: На клиенте юзер заводит большой документ, в формировании которого используется куча связанных таблиц, представленных на клиенте курсорами клиента. Важно, что требуется сохранять документ целиком, а не в процессе его формирования. Трудность в том что ключи, по которым связаны таблицы (соответствующие identity столбцы) будут известны только после сохранения этих данных на сервере. Решение: Для формирования документа используются временные ключи. После построчного апдейта таблиц на сервер вытаскивается @@identity по головным таблицам и происходит сквозное замещения в дочерних курсорах временных fk на реальное значение. Можно ли проще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2001, 11:34 |
|
||
|
кучка @@identity и что с ними делать?
|
|||
|---|---|---|---|
|
#18+
На мой взгляд, разумно. Дело в том, что в SQL Server нельзя определить Identity, пока ты реально не вставил в таблицу. Можно, конечно, блокировать ее, чтоб никто не встрял, смотреть предыдущий IDENT_CURRENT, и прибавлять к нему IDENT_INCR, но, по-моему, это изврат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2001, 20:18 |
|
||
|
|

start [/forum/topic.php?desktop=1&fid=46&tid=1825604]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 331ms |

| 0 / 0 |
