Ошибка: The conversion of a chat data type to a datetime data typ

← →
Shlomo © (2006-02-20 12:40) [0]

Ошибка: The conversion of a chat data type to a datetime data type resulted in an out-of-range datetime value.?

Господа, помогите, пожалуйста, разобраться. Написал программу в неё нужно вводить дату «чч.мм.гггг», точнее, вводить дату нужно в MaskEdit. Затем запускается процедура в программе, которая переводит эту дату в американский формат для запроса на SQLServer. У меня всё работает нормально без ошибок, и у многих других тоже, но вот на одном компьютера выдаётся такая ошибка, он находится далеко, и мне с расстояния нужно понять, в чём тут дело.

← →
API (2006-02-20 12:51) [1]

В настройках системы формат даты - отличный от... как Вы сказали?... кхм... "американского формата"...

При каждом старте программы выполняйте:

SET DATEFORMAT mdy

(Вы это назвали "американским форматом"?)

Настройка временно-локальная, действует только в данной сессии данного пользователя.

Ну, или забирайтесь в настройки конкретного удаленного SQL сервера, разбирайтесь, отчего там формат даты - не "американский".

← →
Shlomo © (2006-02-20 15:17) [2]

API,

Спасибо за ответ. Проблема в том, что все настройки формата времени на SQLServer-е и на локальном компьютере нормальные, на SQLServer-е – американский формат, на локальном компьютере – Русский.
И потом, если бы проблема была в SQLServer-е разве ни увидел бы я тогда в начале ошибки «SQL…»? В связи с чем, я решил, что проблема не в SQLServer-е.

← →
API (2006-02-20 19:13) [3]

И потом, если бы проблема была в SQLServer-е разве ни увидел бы я тогда в начале ошибки «SQL…»? В связи с чем, я решил, что проблема не в SQLServer-е.

Это проблема SQL сервера. Напишите простой запрос с использованием даты, например, "40.40.2006" - увидите то же сообщение.

Проблема в том, что все настройки формата времени на SQLServer-е и на локальном компьютере нормальные, на SQLServer-е – американский формат, на локальном компьютере – Русский.

Выберите что-то одно. Как установить DATEFORMAT в SQL Server"е - я уже написал. Если уж привязались к формату mdy - так и пропишите при запуске приложения эту строку, см. [1].

И еще.
А почему Вы не используете параметры в запросах?
На это есть веская причина?

← →
Shlomo © (2006-02-21 06:24) [4]

Это проблема SQL сервера. Напишите простой запрос с использованием даты, например, "40.40.2006" - увидите то же сообщение.

Да, вы абсолютно правы! Как я раньше не догадался.
Но почему это происходит? У нас на предприятии несколько одинаковых серверов с SQLServer-ами, у всех одинаковые настройки, и почему только с этим такие загвоздки? Причём, если подключаться к этому серверу с другого компьютера всё работает нормально. Я здесь не могу уловить логики.

А почему Вы не используете параметры в запросах?

В каком смысле?

← →
evvcom © (2006-02-21 08:51) [5]

> Это проблема SQL сервера.

Ух! Как самоуверенно! Какие дураки, оказывается, в мелкософте сидят!

> Затем запускается процедура в программе, которая переводит
> эту дату в американский формат для запроса на SQLServer

Зачем? Есть же параметры типа дата, которые не зависят ни от "американского", ни от "русского" формата даты, ни от какого другого. Программы надо писать независимые от региональных настроек ни сервера, ни рабочей станции, а не срамиться, переваливая свои ошибки на плечи/головы других, которые знают и умеют поболее вашего.

← →
easy © (2006-02-21 10:03) [6]

передавайте дату в формате yyyymmdd

← →
API (2006-02-21 12:11) [7]

2 Shlomo ©
А почему Вы не используете параметры в запросах?
В каком смысле?

Вы не указали, какие компоненты используете для доступа к данным - TQuery, TADOQuery, TADODataSet или какие-то другие.
В любом случае, независимо от их класса, поищите в них свойство "Params", "Parameters" - это параметры. Я думаю, для Вас не составит труда разобраться с их использованием.

Не мудрствуя лукаво, пример из help"а:

Query2.SQL.Clear; Query2.SQL.Add("INSERT INTO COUNTRY (NAME, CAPITAL, POPULATION)"); Query2.SQL.Add("VALUES (:Name, :Capital, :Population)"); Query2.Params[0].AsString := "Liechtenstein"; Query2.Params[1].AsString := "Vaduz"; Query2.Params[2].AsInteger := 420000; Query2.ExecSQL;

2 evvcom ©

Извините, но Вы конференцию перепутали.
Это - "Основная".
"Прочее" - по коридору, налево.

← →
Shlomo © (2006-02-22 08:41) [8]

API,

Я думаю, для Вас не составит труда разобраться с их использованием.

Да, конечно, спасибо!

← →
evvcom © (2006-02-22 09:08) [9]

> Извините, но Вы конференцию перепутали

И чем же это я ее перепутал? Ты все же считаешь, что работать с датами через строки - это нормально? Поэтому проблемы все же SQL сервера? В том, что сервер не научился телепатировать, в каком же текстовом виде ты сегодня решил ему дату подсунуть?
Чтобы вступать в подобные споры, ты бы хоть анкетку себе завел, а то сегодня ты API, а завтра ляпнул чего не того и уже под новым ником с чистой совестью. Удобно, блин.

> Это - "Основная".

Вот именно.

← →
API (2006-02-22 10:20) [10]

evvcom
Ты все же считаешь, что работать с датами через строки - это нормально?

Что характерно, в SQL работа с датами ведется именно через строки.
Более того, сам SQL подразумевает использование только текста в запросах.
Так что работать с датами через строки - нормально.
Или для вас это в новинку?

А уж кто формирует текст SQL - я, или компонент, или провайдер - это ВАС волновать не должно.

Параметры используются лишь для облегчения жизни прораммистов. На основании параметров компонент или провайдер формирует текст запроса.
Но всех возможных случаев предсмотреть не удастся, и иногда необходимо передавать дату в виде строки. И если этот текст формирую я, то ответственность за правильное формировании лежит на мне. Все очень просто...

Именно о формировании правильного текстового представления даты в SQL запросах и ведется речь в данной ветке.

Вы же пришли сюда и несете какую-то чушь, указывая что можно и чего нельзя.
Надо будет - буду напрямую коннектится к SQL серверу по TCP/IP и сам реализовывать протокол обмена данными.
Это - мое, но НЕ ВАШЕ ДЕЛО.

Так что... "заткнись, Хью, пожалуйста" (С)...

evvcom
Чтобы вступать в подобные споры, ты бы хоть анкетку себе завел, а то сегодня ты API, а завтра ляпнул чего не того и уже под новым ником с чистой совестью. Удобно, блин.

Ваше плевание на чистоту моей совести не влияет.
Мне, собственно, совершенно пофиг.
И еще. В контексте "ляпнул чего не того и уже под новым ником" - я бы порекомендовал вам сменить ник.
С этого поста - игнор вам, Вячеслав из Домодедово.
Хотя, откуда мне знать, может, вы - Беня из Хайфы?
Почему я должен верить вашей анкете, вами же написанной?
Тьфу...

← →
evvcom © (2006-02-22 10:43) [11]

> Что характерно, в SQL работа с датами ведется именно через
> строки.

Бред.

> Более того, сам SQL подразумевает использование только текста
> в запросах.

Бред.

> Так что работать с датами через строки - нормально.

Не забывай "ИМХО" ставить. А то можно подумать, что существует только 2 мнения: твое и неправильное.

> Или для вас это в новинку?

Не в новинку. На заре своей молодости использовал пару раз. Заимел те же проблемы, перешел на параметры. Больше таких проблем не имел никогда.

> Вы же пришли сюда и несете какую-то чушь
> Так что... "заткнись, Хью, пожалуйста" (С)...

Продолжать в дальнейшем диалог с агрессивно настроенным юнцом не вижу смысла.

← →
API (2006-02-22 11:54) [12]

evvcom

У-у-у-у... как все запущено...
"Бред, бред, бред",- и ни одного аргумента.
Навязываемой другим аббревиатуры "ИМХО", кстати, в тексте тоже не видно.
Вы уж, если от других требуете, то и сами применяли бы.
Хотя, мне ваше "ИМХО" - до одного места.
Меня интересуют аргументы.
Кроме "это нельзя, это проблематично", я аргуметов не услышал.
Если вам нельзя, если для вас проблематично,- то это ваши проблемы.

Итак, начинаем процесс обучения Вячеслава основам SQL.

SQL - Structured Query Language, язык структурированных запросов.

Повторю: язык. Поэтому, любая конструкция SQL - суть текст.
Это понятно?

Если хотите кричать "бред" - сопровождайте его контраргументами и контрпримерами.

Вижу в последнем посте агрессия схлынула. Ну что ж аргументы?

> Кроме "это нельзя, это проблематично", я аргуметов не услышал.

По Ctrl+F такая цитата находится только в [12], ну и в этом посте теперь найдется. Это чье изречение?

> Итак, начинаем процесс обучения Вячеслава основам SQL.

О как! Ну-с, слушаю...

> Повторю: язык. Поэтому, любая конструкция SQL - суть текст.
> Это понятно?

В таком случае "Суть - текст" будет справедливо для любого языка и не только. Даже в шестнадцатиричном/двоичном редакторе мы видим на экране монитора графическое изображение, по сути являющееся текстом, пусть даже этот текст состоит только из "0" и "1". Это мы так далеко уйдем.
Только обучающийся Вячеслав задает тогда такой вопрос учителю. А известно ли Вам, дорогой учитель, что в любом языке программирования в том или ином виде реализована поддержка типов данных? Что тексты программы в конце концов компилятор/интерпретатор/транслятор преобразовывает к некоему коду с учетом типов данных, а не просто каких-то абстрактных текстов?

> Если хотите кричать "бред" - сопровождайте его контраргументами
> и контрпримерами.

Пожалуйста.

> > Что характерно, в SQL работа с датами ведется именно через
> > строки.
> Бред.

есть тип данных в SQL date. Я пишу, например, так:
insert into MyTable (MyDateField) values (:MyDateParam)
Вопрос: где здесь работа "именно через строки"?

> > Более того, сам SQL подразумевает использование только текста
> > в запросах.
> Бред.

Если иметь в виду

> Поэтому, любая конструкция SQL - суть текст.

то да. Тогда любой язык подразумевает использование только текста. Естественно, что человек общается с компьютером посредством ввода/вывода какого-то текста, мы еще не научились передавать свои желания и получать ответы от компьютера посредством усилия воли/мысли и сразу в двоичном коде. Мы же не на уроке философии!

← →
API (2006-02-22 14:24) [14]

А известно ли Вам, дорогой учитель, что в любом языке программирования в том или ином виде реализована поддержка типов данных? Что тексты программы в конце концов компилятор/интерпретатор/транслятор преобразовывает к некоему коду с учетом типов данных, а не просто каких-то абстрактных текстов?

Что характерно, то, что делает компилятор/интерпретатор/транслятор внутри себя с переданным ему текстом - ни вам, ни мне - не известно.
Важно другое: входные данные для компилятора/интерпретатора/транслятора - чистый текст.
В случае с компилятором/линковщиком Delphi (я возьму его для примера), параметры компиляции/линкования могут быть заданы как в командной строке в виде параметров командной строки, так и в виде текстовых директив внутри самого исходного текста. Утверждать, что определять ход компиляции и линкования рекомендуется только из командной строки - слишком самоуверенно. Запрещать использовать директивы в тексте программы, и утвержать, что это ненормально - тоже слишком самоуверенно. Все способы возможны и хороши.

insert into MyTable (MyDateField) values (:MyDateParam)

Это ВЫ пишете в СВОЕМ компоненте в Delphi.
По пути от вашего компонента к процессору SQL сервера, MyDateParam заменяется вашим компонентом или провайдером на текстовое значение даты, понятное SQL серверу. Это ваш компонент или провайдер запрашивает формат даты у сервера, и преобразовывает дату в текстовый формат, понятный серверу.

SQL-сервер запрос в предоставленном вами виде (без преобразований) не поймет. Он работает только с текстовыми SQL-конструкциями.
Возьмите консоль MS SQL сервера, введите этот ваш запрос, и постарайтесь уговорить сервер его выполнить. О результатах - телеграфируйте.

Еще раз: ":MyDateParam" понятен только вашему компоненту и провайдеру, но не SQL-серверу.

Еще раз: Параметры - это прослойка между вами и SQL-сервером, введенная для упрощения вашей жизни в общих случаях. Но это - в общих случаях. На практике часто встречаются случаи, когда использование параметров невозможно или затруднительно. И в таких случаях передать дату в текстовом виде - самое логичное и простое решение.

Еще раз: Передача даты в текстовом виде - это - нормально. То есть, согласно стандартов SQL - это - (практически) единственный способ передать дату в тексте SQL напрямую к SQL серверу. То есть, других путей, в общем случае, не имеется (частные случаи реализации SQL серверов рассматривать не будем, надеюсь...).

Поэтому "где здесь работа "именно через строки"?" - посмотрите профайлером текст запроса, попавший на вход процессора SQL-сервера.

Даже в шестнадцатиричном/двоичном редакторе мы видим на экране монитора графическое изображение, по сути являющееся текстом, пусть даже этот текст состоит только из "0" и "1".

Особенно если это бинарник программы, то предложенный вами вариант - практически бесполезен...

Чтобы вам было понятнее, о чем я говорю, рассмотрим два варианта:

38770 и "22.02.2006"

38770 - это числовое представление сегодняшней даты в TDate
"22.02.2006" - это текстовое представление сегодняшней даты

Комментарий: Что характерно, MS SQL-сервер поймет и то, и другое (передать только правильно надо). Проблема в том, что TDateTime (в Delphi) смещен относительно DateTime (MS SQL server) на 2 дня. Ваш компонент или провадер знает об этом смещении и учитывает его при переводе вашей даты в строку при передаче запроса серверу.

Так вот, возвращаясь к вопросу текстового представления даты.
Дата (и время) передается на процессор сервера НЕ как 4-байтовое целое, не как 8-байтовое (или n-байтовое) с плавающей запятой, НЕ как некий другой абстрактный тип данных, а именно как строка "22.02.2006" (хотя, в зависимости от провайдера, настроек сервера и пр этот формат может отличатся... (никто не запретит некоему "доморощенному" провайдеру передать и 38770)... это и вам и мне понятно).

Поэтому еще раз: SQL сервер получает на входе текстовое представление даты, а не бинарное; процессор SQL-сервера не знает, что такое TDateTime. И кем производится преобразование даты - вами, вашим компонентом или провайдером - не важно.

То есть, если по условиям задачи необходимо использовать текстовое представление даты в SQL-запросе, то никто этого запретить не сможет. Более того, это - родной и единственный формат SQL-процессора.

То есть, использование строчного представления при передаче даты - это НОРМАЛЬНО.

И еще, по поводу [5].
Если дата будет передана в неправильном формате, будет сгенерировано исключение. Источник исключения - SQL-сервер, а не программа или провайдер. Именно об этом сказано в [3]. Читайте внимательней, прежде чем иронизировать...

> insert into MyTable (MyDateField) values (:MyDateParam)
> Это ВЫ пишете в СВОЕМ компоненте в Delphi.

Нет. Это я пишу в хранимой процедуре. Различие для MSSQL: @MyDateParam, для Оракла без ":" и без "@".

> По пути от вашего компонента к процессору SQL сервера, MyDateParam
> заменяется вашим компонентом или провайдером на текстовое
> значение даты, понятное SQL серверу.

Нет. Если используются параметры, то и передается как параметр. С MSSQL работал давно, но и там, по-моему, в этом случае уходит строка вида:
insert into MyTable (MyDateField) values (:MyDateParam)
именно с ":". Оракл предобрабатывает такой запрос и в Shared Pool попадает курсор insert into MyTable (MyDateField) values (:b1). Таким образом, получив текст insert into MyTable (MyDateField) values (:MySuperParam), он все равно преобразует его к insert into MyTable (MyDateField) values (:b1), сэкономив место в Shared Pool. Далее имеется такое понятие как Parameter Binding (привязка параметров), во время чего и происходит передача двоичных данных.

> Что характерно, MS SQL-сервер поймет и то, и другое (передать
> только правильно надо).

Вот! Правильно! Поймет. Но это противоречит заявлению

> Что характерно, в SQL работа с датами ведется именно через
> строки.

И это не мое заявление, замечу, на что я и ответил коротко "Бред".

Вот интересно, а что это за "американский формат" и "Русский формат"???
:)))))))))))))))))

> случае уходит строка вида:
> insert into MyTable (MyDateField) values (:MyDateParam)
> именно с ":".
не совсем точно, преобразовывается в "insert into MyTable (MyDateField) values (?)"

Ошибка: The conversion of a chat data type to a datetime data typ Найти похожие ветки