Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 timestamp - Вопрос чайника  [new]
KonstantK
Member

Откуда:
Сообщений: 13
Читал описание:
http://technet.microsoft.com/ru-ru/library/ms182776(SQL.90).aspx
Это тип данных, который представляет собой автоматически сформированные уникальные двоичные числа в базе данных.
Тип данных timestamp используется в основном в качестве механизма для отметки версий строк таблицы.
Размер при хранении — 8 байт. Тип данных timestamp — всего лишь увеличивающееся значение, которое не сохраняет дату или время.
Тип данных datetime используется для записи даты или времени.

При миграции БД из ACCESS в MSSQL2008 использовал Microsoft SQL Server Migration Assistant 2008 for Access, который создал в каждой таблице поле SSMA_TimeStamp. В моем приложении поле нигде не используется.

Вопрос: используется ли это поле каким-либо образом самим MSSQL? Иными словами, если я его удалю - отразиться ли это как-то на работе приложения\БД?
15 дек 09, 14:50    [8069452]     Ответить | Цитировать Сообщить модератору
 Re: timestamp - Вопрос чайника  [new]
PokeMan
Member

Откуда: MOSKAU
Сообщений: 312
Если вам Access уже не нужен, то можно и удалить. т.к. оно нужно скорее Access-у, а не MSSQL.
Подробнее. зачем оно нада см. ниже. Еще подробнее в доке к Microsoft SQL Server Migration Assistant 2008 for Access

MSDN
Understanding and Addressing Updatability Issues
After migrating native Access tables to linked SQL Server tables, you may find that some of your Access queries, or even some of your tables, are no longer updatable. You also may encounter updatability issues with linked SQL Server views.
To diagnose and fix these problems, you need to understand the capabilities that Access relies on when performing updates. As discussed previously in Using Pass-Through Queries to Optimize Bulk Updates, all Access updates are based on dynasets. Access needs a set of unique keys for any rows being updated. Access also needs a way to verify that the rest of the data in each row to be updated hasn’t changed since the data was retrieved. In addition, you must contend with the fact that, unlike the Access database engine, the SQL Server database engine assumes that a single update statement can only modify columns in a single table. The Access database engine has a different set of rules affecting what types of queries can be updatable.
Specifying a unique index
If you find that a linked table or view is not updatable, see if the link has been assigned a unique index in Access. To do this, open the linked table in design view (click Yes in the dialog box that asks if you want to continue even though some design properties of linked tables can’t be modified). You should see the familiar primary key icon to the left of a column or set of columns in the table. If you don’t see this, Access isn’t able to open dynasets that include this linked table.
In Adjusting Dynaset Behavior earlier in this paper, you learned how Access selects this index and how you can execute SQL statements in Access to designate a unique index. If the link is to a table, you can also create a new unique index on the server and recreate the link. For views, you can recreate the link and select one or more columns in the dialog box that appears after you select the view. It is not necessary to create an index for the view on the server.
Supporting concurrency checks
Probably the leading cause of updatability problems in Access linked tables is that Access is unable to verify whether data on the server matches what was last retrieved by the dynaset being updated. If Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Access is unable to check reliably for matching values. These include large object types such as text, ntext, image, and the varchar(max), nvarchar(max), and varbinary(max) types introduced in SQL Server 2005. In addition, floating point numeric types, such as real and float, are subject to rounding issues that can make comparisons imprecise, resulting in cancelled updates when the values haven’t really changed. Access also has trouble updating tables containing bit columns that do not have a default value and that contain null values.
A quick and easy way to remedy these problems is to add a timestamp column to the table on SQL Server. The data in a timestamp column is completely unrelated to the date or time. Instead, it is a binary value that is guaranteed to be unique across the database and to increase automatically every time a new value is assigned to any column in the table. The ANSI standard term for this type of column is rowversion. This term is supported in SQL Server.
Access automatically detects when a table contains this type of column and uses it in the WHERE clause of all UPDATE and DELETE statements affecting that table. This is more efficient than verifying that all the other columns still have the same values they had when the dynaset was last refreshed.
The SQL Server Migration Assistant for Access automatically adds a column named SSMA_TimeStamp to any tables containing data types that could impact updatability.
Note that data types that cause updatability problems can also cause problems when included in keysets. If Access fails to find a matching value on the server, it assumes that the row has been deleted. When choosing unique identifiers, pick columns with values that can be matched reliably.
15 дек 09, 15:38    [8069834]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить