У меня БД в SQL Server, а приложение в Delphi. Для доступа пользуюсь компанентами ADO.
При попытке сделать Update поля с датой типа DateTime выдается ошибка: Дополнительная возможность не реализованна.
Код:
ADOQuery8.Close;
ADOQuery8.SQL.Clear;
ADOQuery8.SQL.Add('update znakomue set day_rojd= where id=5');
ADOQuery8.Parameters [0].Value := Edit1.Text ;
ADOQuery8.ExecSQL;

Помогите, пожалуйста. Подскажите, где я ошибаюсь.
Заранее спасибо!!!

Но лучше дату передавать как дату, это позволит избежать проблем если национальные установки клиента и сервера разные:

он все равно пишет ошибку: Project1.exe raised exception class EConverError with message "a ' is not a valid date and time'.Process stopped.
независимо от того как вводишь дату: с помощью точек, слешей или запятых.

HELP ME, PLEASE

По видимому в моём коде такую ошибку может генерить только StrToDateTime, каклй у вас формат даты установлен на компьютере? Попробуйте выполнить следующую строку:

Showmessage(datetimetostr(now))

и посмотрите на то в каком формате будет выведена дата, в таком же формате попробуйте ввести её в edit. Кроме того хотелось бы знать в каком именно месте происходит ошибка, видоизмените код:

У меня формат даты: дд.мм.гггг

Изменила код на предложенный вами, но все равно вылетает та же ошибка: Project1.exe raised exception class EConverError with message "a ' is not a valid date and time'.Process stopped.

Что еще можно попробывать?

Такого не бывает потому что не бывает никогда! Я специально добавил в код несколько try..except с подробным описанием ошибки, чтобы идентифицировать строку которая генерит ошибку, если вы это описание в ввиде сообщения не получили, а получили голое сообщение о системной ошибке, значит:

1. Вы не заменили код
или
2. Ошибку генерит вовсе не приведенный код
или
3. Вы запускаете в режиме отладки с перехватом дебуггером дельфи всех ошибок и вместо того чтобы привести сообщение об ошибке которое генерит код указываете мне сообщение об ошибке которое выдаёт дебуггер (в этом случае при появлении ошибки нажмите Ok, затем F9 в Дельфи, когда программа продолжит работу она выдаст сообщение которое я генерю - вот его-то и надо привести здесь, иначе очень трудно понять чего у вас там происходит)

У меня третий вариант.

Выскакивает ошибка:
Error executing query
[Microsoft][ODBC SQL Server Driver] Дополнительная возможность не реализованна

Собственно, это тоже самое, что у меня было вначале.
Это хорошо или плохо? И что с этим вообще делать?

Хм... очень странно, а вот так работает:



Кстати какого типа поле day_rojd в таблице?

АААААААА!!!!!!!

СУПЕР
Все работает
Спасибо вам ОГРОМЕННОЕ, вы мне очень помогли

Хм... я то почти и не сомневался что так работает, настараживает тот факт что предыдущий вариант не работал... Очень странно...

А меня уже ничего не удивляет.
Главное, что работает! И я этому безумно рада

Я рад что Вы рады... но обойдя одни грабли случайно стороной не гарантирует шишки следующий раз. Дело Ваше, но желательно разбираться до конца... Это помогает в будущем, по существу вопроса:

Дата в формате yyyy-mm-dd hh:nn:ss является стандартом для MS SQL Server и при ЛЮБОЙ локализации клиента и сервера строка в таком формате конвертируется в дату правильно

если это является стандартом, почему же тогда в таблицах SQL Serverа он выводит дату как dd.mm.yyyy? и в приложение он выводит дату в таком же формате
У меня что, нестандартные настройки в SQL Serverе стоят? но как это может быть, если я ничего не меняла?

Нет, попробую расставить точки над i.

1) MS SQL Server сам по себе хранит дату в ввиде дробного числа, где целая часть это число дней пошедших с 30 декабря 1899 года, а дробная - это части дня. Попробую объяснить при помощи псевдокода:

если у вас есть в поле дата "21 марта 2006 года, 21:10:00" то
- если взять целую часть от даты то будет "21 марта 2006 года"
- если взять дробную часть от даты то будет "30 декабря 1899 года, 21:10:00"
- один час равен 1/24 единицы в том поле
- одна минута равна 1/(24*60)

2) Когда вы вставляете в запрос дату в кавычках, то сервер вначале конвертирует её в своё представление в ввиде дробного числа, а потом оперирует им. НО! Конвертация зависит от используемых национальных установок, вы пишете на дельфи например StrToDateTime('01/02/03') и на вашем компьютере стоят национальные установки российские, то эта функция вернёт дату "01 февраля 2003" года, а если у вас стоят американские установки то эта эе функция вернёт "02 января 2003" года. Обычно при работе с обычным приложением вам на это наплевать, главное что дата всегда конвертируется в пределах вашего приложения одинаково, соответственно вашим национальным установкам. А вот когда начинаем работать с сервером возникают проблемы: у вас может быть русская локаль, а на сервере - американская и строка даты '01/02/03' для сервера и клиента означают РАЗНЫЕ даты! То что я пытался сделать вначале - это послать дату в формате даты, а не строки параметром и предоставить серверу самому интерпретировать её... и был очень удивлён что у Вас это не работает.

3. Когда вы выводите информацию из базы данных, например в грид, то клиентское приложение естественно пытается конвертировать дату из дробного числа в строку, которая была бы понятна для вас, так как вряд ли вы сможете оперировать легко и наглядно с датами записанными как 36263.21312. Даже когда вы просматриваете базу данных используя Query Analyser или MS SQL Server Enterprise Manager - они являются обычными клиентскими программами, такими же как и ваше приложение. Они при показе даты будут и производить конвертацию дробного числа с сервера в строку. Причём существует 4 вида алгоритма конвертации:
- Использовать какой-то стандартный, зашитый формат
- Использовать формат даты/времени установленный на компьютере где стоит сервер
- Использовать формат даты/времени установленный на компьютере где стоит клиент
- Не заморачиваться и показывать как бог на душу пошлёт... как многие программисты и делают, даже в MS. Итого: выводит дату в формате dd.mm.yyyy КЛИЕНТСКОЕ приложение а не сервер, формируя её по видимому с учётом ваших локальных клиентских установок, а вот когда вы формируете запрос в таком формате, то сервер получив такую строку и (по-видимому) имея какие-то другие настройки просто не способен её переварить.

Итого то что показывает грид - к реальности имеет весьма отдалённое отношение.

4. Программисты из MS предвидели проблемы с конвертацией строк с датой в данные типа "дата-время", поэтому выработали стандарт который позволяет при любых национальных раскладках интерпретировать строку формата YYYY-MM-DD HH:NN:SS всегда правильно. Например у меня стоит американская раскладка и запросы


и


Для моего MS SQL Server абсолютно идентичные, хотя на вашем сервере с русской нацинализацией, только первый мой запрос будет правильным, второй для вас надо будет менять на



Пока вы работаете в пределах одной и той же локалицации вы можете использовать оба запроса, но предпочтителен вариант '2006-01-02' - так как именно он будет гарантировать выполняемость запроса при любых установках сервера

Спасибки!
Объяснения знающего человека всегда воспринимаются легче, чем текст какой-нибудь книги. Да и не в любой книге найдешь нужную информацию.