![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Полтергейсты SQL Server или всё "намана"? [D7, MSSQL]
31512 © (2004-03-26 09:10:00)Дело было так ... Моя мечта попробовать создать трёхуровневое приложение для базы данных (SQL Server 2000), с некоторых пор начала обретать физическую форму. Для создания самоей БД на сервере я сначала использовал Access. Ну, чего проще? Сляпал БД, вызвыл "Мастер преобразования в формат SQL Server" и ... собственно больше ничего не требуется. Но потом мне надоело каждый раз лезть в Access, когда возникала необходимость создать БД заново. Тогда я написал SQL-скрипт, как говорится, "в раз и навсегда", внося по мере необходимости в него ихменения. А заставить SQL серевер выполнить SQL-скрипт не так уж сложно, да и быстрее это раз в 30.
Но вот какая фигня стала происходить. В случае создания БД Accessом, достаточно было выставить нужные флаги у DataSetProviderов для серверного приложения, чтобы в клиентском приложении при вызове метода TClientDataSet.ApplyUpdates(ErrorCount : integer) все изменения аккуратно принимались, в том числе происходили и корректные изменения в самой БД. При этом никаких дополнительных действий принимать не требуется, т.е. используются самые стандартные возможности DBшных компонентов. Однако, если БД создана посредством скипта, то ничего подобного не наблюдается. Вставить новую запись - без проблем, но на удаление и изменение получаю ошибку "Запись была изменена или занята другим пользователем" сообщением "Не удалось найти запись". И только создание бизнес-правила в методе TRemoteDataModule.DataSetProviderBeforeUpdateRecord
позволяет выполнять всё корректно. Почему же возникают, как говорят в Одессе, такие "две большие разницы"?
У меня: D7, SQL Server 2000, WinXP SP1 RUS, Office XP(with FrontPage), ADO (MDAC 2.7), MIDAS.
31512 (2004-03-26 09:49:00) [41]Для bushmen
CURRENT_TIMESTAMP - Returns the current date and time. This function is equivalent to GETDATE(). Так написано в HELPе по Transact-SQL. Просто по умолчанию в поле надо писать текушую дату.
bushmen (2004-03-26 09:39:00) [42]А зачем ты timestamp кидаешь в поле datetime? Есть же специальный тип в SQL - timestamp
Nikolay M. (2004-03-26 09:38:00) [43]
> TField.ProviderFlags.pfInKey - идентефикация с помощью первичного
> ключа БД
Не совсем понял твое понимание этого флага, надеюсь, оно правильное. Так же, как и понимание свойства TDataSetProvider.UpdateMode.
> А SQL скриптом как флаги у полей выставлять?
Не, давай мухи отдельно, котлеты отдельно. При чем тут скрипт, который выполняется на сервере и флаги, которые выставляются на клиенте?
31512 (2004-03-26 09:35:00) [44]Вот, кстати, кусок скрипта, создание одной 2х таблиц
create table [ORGANISATION](
ID_ORGANISATION int identity(1, 1) not null primary key,
ORGANISATION_NAME nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
ORGANISATION_ADRESS nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
ORGANISATION_CODE nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
DBDATE datetime not null default CURRENT_TIMESTAMP,
DELETED bit not null default 0
)
create table [EMPLOYEE](
ID_EMPLOYEE int identity(1, 1) not null primary key,
ID_ORGANISATION int not null foreign key references ENERGO_DB.[dbo].[ORGANISATION](ID_ORGANISATION) on delete cascade,
EMPLOYEE_NAME nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
EMPLOYEE_POST nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
EMPLOYEE_PHONE nvarchar (255) collate Cyrillic_General_CI_AS not null default 'Нет данных',
DBDATE datetime not null default CURRENT_TIMESTAMP,
DELETED bit not null default 0
)
31512 (2004-03-26 09:32:00) [45]Для Nikolay M.Очень даже может бытьююю. И один из таких флагов ... в Делфи TField.ProviderFlags.pfInKey - идентефикация с помощью первичного ключа БД ....
А SQL скриптом как флаги у полей выставлять?
Nikolay M. (2004-03-26 09:21:00) [46]
> В случае создания БД Accessом, достаточно было выставить
> нужные флаги у DataSetProviderов для серверного приложения,
> чтобы в клиентском приложении при вызове метода TClientDataSet.ApplyUpdates(ErrorCount
> : integer) все изменения аккуратно принимались
Возможно, необходимые флаги у полей сбрасываются (не выставляются)?