если в sql запросе при заполнении текстового поля получается комбинация символов "М" , где М - русская , значения поля по таблице для всех записей становится одинаковым. В том случае если символ латиницы , запрос просто не отрабатывает
sql ->
UPDATE tkan SET artik="12345"М"",perep=1,oborud=5,plot=160,diam=2,X1=0.3,X2=0,X3=0.6,X4=2,X5=0.5,kfus=0.985,Shir=88 where uniknum=201
русский текст в двойных кавычках
Нашел еще один интересный баг по типу первого. Если попробывать выполнить update поля Stoim типа Dobule Precision
IBSQL_Avto.Close;
IBSQL_Avto.SQL.Clear;
IBSQL_Avto.SQL.Add('update Avto');
IBSQL_Avto.SQL.Add('set Stoim=10 000,');
IBSQL_Avto.SQL.Add('where ID="'+ID_Avto+'"');
IBSQL_Avto.Transaction.StartTransaction;
IBSQL_Avto.ExecQuery;
try IBSQL_Avto.Transaction.Commit; except IBSQL_Avto.Transaction.RollBack; end;
и при этом заносить туда число разделенное пробелом, то возникает исключительная ситуация, по поводу неправильного числа, но commit проходит все равно и все значения таблицы модифицируются и становятся одинаковыми.
На сервере стоит Fb 1.5.3 Ss
IBSQL_Avto.Close;
IBSQL_Avto.SQL.Clear;
IBSQL_Avto.SQL.Add('update Avto');
IBSQL_Avto.SQL.Add('set Stoim=10 000,');
IBSQL_Avto.SQL.Add('where ID="'+ID_Avto+'"');
IBSQL_Avto.Transaction.StartTransaction;
IBSQL_Avto.ExecQuery;
try IBSQL_Avto.Transaction.Commit; except IBSQL_Avto.Transaction.RollBack; end;
и при этом заносить туда число разделенное пробелом, то возникает исключительная ситуация, по поводу неправильного числа, но commit проходит все равно и все значения таблицы модифицируются и становятся одинаковыми.
На сервере стоит Fb 1.5.3 Ss
страсти какие то. может и баг, но лучше бы ты привел
результирующую строку, которая едет на сервер
И -
1. числа не надо передавать на сервер как строки. то есть
where id = "43 44"
нужно считать извратом.
2. уже давно не надо использовать двойные кавычки
3. приведенный код - потенциальная дыра в безопасности.
оператор может ввести вместо числа
0" or id = 10'
и тогда будет примерно то же самое, что в твоей ситуации
следовательно число в строке перед его отправкой на сервер надо бы или проверять на "численность" через strtoint, или присваивать через параметр (что то же самое - params[x].asInteger:=strtoint(Edit1.Text))
результирующую строку, которая едет на сервер
И -
1. числа не надо передавать на сервер как строки. то есть
where id = "43 44"
нужно считать извратом.
2. уже давно не надо использовать двойные кавычки
3. приведенный код - потенциальная дыра в безопасности.
оператор может ввести вместо числа
0" or id = 10'
и тогда будет примерно то же самое, что в твоей ситуации
следовательно число в строке перед его отправкой на сервер надо бы или проверять на "численность" через strtoint, или присваивать через параметр (что то же самое - params[x].asInteger:=strtoint(Edit1.Text))
Результирующий код выглядит так
update Avto
set Datamod="13.10.2006",
gosn="A425AA36",
ID_TipKuz=2, INVN="04.0000621", NDvig="ARG023100",
NShassi="отсутствует", Kol_kol=5,
.....
Stoim=470 000,
Nsp=Null,
Datasp=Null,
....
probegAll=174 399
where ID="00000000000000000009"
Насчет передачи в чисел как строк так сложилось исторически, именно для этой таблицы и еще парочки.
База на первом диалекте поэтому двойные кавычки нужны.
Насчет всего остального у меня стоит запрет на ввод. А пробел нужен для разделения разрядов в числе. Я его убиваю преред вставкой, но если его не удалить, то это приводит к таким печальным последствиям.
При это выдается следующее исключение (Exception EConvertError in module ..... '174 399' is not a valid floating point value), но коммит проходит.
update Avto
set Datamod="13.10.2006",
gosn="A425AA36",
ID_TipKuz=2, INVN="04.0000621", NDvig="ARG023100",
NShassi="отсутствует", Kol_kol=5,
.....
Stoim=470 000,
Nsp=Null,
Datasp=Null,
....
probegAll=174 399
where ID="00000000000000000009"
Насчет передачи в чисел как строк так сложилось исторически, именно для этой таблицы и еще парочки.
База на первом диалекте поэтому двойные кавычки нужны.
Насчет всего остального у меня стоит запрет на ввод. А пробел нужен для разделения разрядов в числе. Я его убиваю преред вставкой, но если его не удалить, то это приводит к таким печальным последствиям.
При это выдается следующее исключение (Exception EConvertError in module ..... '174 399' is not a valid floating point value), но коммит проходит.
ерунду писать не надо. в первом диалекте что одинарные что двойные кавычки - все равно. избежание двойных кавычек уменьшит головную боль при переходе на третий диалект, если такой состоится.База на первом диалекте поэтому двойные кавычки нужны.
то есть. на СЕРВЕРЕ никакого exception нет. exception eConvertError сугубо клиентский, и в том, что тем не менее запрос отправляется на сервер, виноваты или компоненты или ваше приложение.При это выдается следующее исключение (Exception EConvertError in module ..... '174 399' is not a valid floating point value), но коммит проходит.
Все дело в символе с кодом #160, который очень похож на пробел, но не он, так как у пробела код #32. Так вот если в запросе рукими внести число с пробелом, например (1 000), то все нормально генерируется исключение, а если это же число получить использую функцию FormatFloat ('#,###.##', 1000), то сервер исключение не генерируется и все что будет после этого символа просто не видно для сервера.
В первом случае имеет код #32, а во втором код #160.
Очень опасно если такая ситуация возникнет при update записи, условие where игнорируются, и все данных модифицируются под одну редактируемую запись.
Я так по не знанию снес таблицу в 1500 записей.
Хорошо, что был бэкап.
В первом случае имеет код #32, а во втором код #160.
Очень опасно если такая ситуация возникнет при update записи, условие where игнорируются, и все данных модифицируются под одну редактируемую запись.
Я так по не знанию снес таблицу в 1500 записей.
Хорошо, что был бэкап.