оффтоп на тему БД из "Эврики"

[Алексей++]

неожиданное, но приятное открыл открытие: как птица (1.5+), так и MySQL 5+ (за другие версии не знаю) умеют понимать обёрнутые в апострофы значения в select, insert и update, а также переданные в процедуру параметры ))

наглядно, вот о чём я

select * from T where num=1 and text='qqq';
update T set num=1, text='qqq';

этому будет эквивалентно:

select * from T where num='1' and text='qqq';
update T set num='1', text='qqq';

то есть, отныне не надо мне выбирать, что обернуть в апострофы, а что нет - можно тупо все параметры обернуть и всё

Только интересно, как это согласуется со стандартом

[Dale]

Текста стандарта под рукой сейчас нет. Посмотрел справку на MS SQL 2008, который не был мной уличен в существенных отличиях от стандарта. Там указано, что типы char и varchar неявно конвертируются почти во все типы, кроме binary, varbinary и timestamp. Все числовые типы заведомо входят в этот список. Так что открытие, возможно, и приятное, но весьма ожиданное.

[Антон (LogRus)]

надеюсь тут нет подводных камней в виде ты ожила что поле сконвертится в одно, а оно сконвертилось в другое

[lapulya]

а причем тут c++? Имхо это в другом разделе обсуждать надо...

[Алексей++]

Антон (LogRus), да фиг знает...

lapulya, да тут все озарения собраны)) Может, стОит и перенести - просто я изначально тут создал, так и поехало

[RXL]

Леш, это для неизвестного числа параметров так можно было бы сделать, да и то очень ненадежно.

Учитывая, что ты пользуешься MySQL, вот лишь некоторые возможные подводные камни:

1. Преобразование hex-константы.
0x80 -  VARBINARY (1 байт со значением 0x80).
"0x80" - VARCHAR.

2. Преобразование BINARY в целое и интерпретация hex-строк в числа.
0 + 0x80 даст 128. Если BINARY длиннее 8 (размер BIG INT), то используются последние 8 байт. Если короче 8 байт, то старшие байты равны 0.
0 + "0x80" даст 0.0. В данном случае это особенность MySQL: если текст не является валидным целым числом, то результат считается плавающими значениями, а интерпретация прерывается на первом неверном символе с генерацией предупреждения (не ошибки!).

Правильно будет использовать bind переменных.

Код: (SQL)

SELECT a, b
FROM tab
WHERE id = ?

Код: (SQL)

UPDATE tab
SET a = ?, b = ?
WHERE id = ?

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

[Алексей++]

ну, вообще-то, я для птицы делаю Просто заодно и на MySQL проверил

1) так у меня не будет, никогда в hex формате в строку SQL не пишу

2) для MySQL - учту. Для птицы у меня для числовых типов только десятичные циферки в строке SQL бывают

Добавлено через 5 дней, 11 часов, 48 минут и 54 секунды:
встретил в птице1,5 неприятную особенность (плюс к тому, что тут всего один уровень транзакции - никаких вложенных) - если внутри транзакции происходит исключение, оно не вырывается наружу, и кажется, что всё ок. Но после коммита оказывается, что сделалось ничего!

в частности, создавал процедру P2, которая в своём теле вызывает процедуру P1(a,b), в то время как P1 ещё было только в стадии заготовки (пустое тело, параметры не описаны). Исключения не выпало. Догадался отключить транзакцию

Код:

	const bool bUseTrans=false; //ТРАНЗАКЦИЮ ОТКЛЮЧИЛИ

	bool bSuccess=false;
	if(!bUseTrans || pbase->BeginTrans())
	{
		TRY
		{
			//тут много операций
			//...

			//если дошли до контрольной точки
			bSuccess=true;
		}
		CATCH(CDBException, e)
		{
		
		}
		END_CATCH

		if(bSuccess)
		{
			if(bUseTrans)pbase->CommitTrans();
		}
		else
		{
			if(bUseTrans)pbase->Rollback();
		}
	}

ошибка сразу выскочила и отладилась. Разрешил снова транзакцию - всё получилось

Добавлено через 34 секунды:
а в MySQL как с похожей ситуацией дело обстоит ?

[RXL]

Леш, если ты про транзакции, то она по стандарту и по определению не может быть вложенной. В некоторых навороченных СУБД все же их реализуют - в Оракл встречал вложенные.

Мне не совсем понятны твои трудности. Обычно ведь как: стартовал транзакцию, выполнил N операторов, commit или по исключению rollback. Что в данной модели тебя не устраивает?

[Алексей++]

так я и не жалуюсь, что нет вложенной. Мне непонятно, почему ошибка не выскочила, когда должна была.

[RXL]

Леш, а что за странные TRY-CATCH?

Добавлено через 2 минуты и 32 секунды:
В MySQL на все будет либо ошибка, либо предупреждение. Но в процедуре, функции или в любом их блоке можно обработать любую (наверно только кроме синтаксической) ошибку и тогда она не будет распространяться дальше.

[Алексей++]

TRY-CATCH-AND_CATCH-CATCH_ALL-END_CATCH
http://msdn.microsoft.com/en-us/library/19z28s5c(v=VS.80).aspx
 - это MFC-ишная приблуда. По МСДН - эти макросы якобы оставлены для совместимости с предыдущими версиями MFC. На практике же, если пользоваться не ими, а try-catch , то будет утечка памяти, если только не удалить эксепшен явно вот таким образом:

Код:

try
{
}
catch(CDBExeption* e)
{
   ...
   e->Delete();
}

[Алексей++]

в птице 1,5 наткнулся на странную вещь:

пусть, имеется таблица T(a,b,c,d). Добавляю ещё поля в транзакции и заполняю их там:

начать трз
  alter table T add E1 smallint;
  alter table T add E2 smallint;
  alter table T add E3 smallint;

  update T set E1=null;
  update T set E2=10;
коммит трз


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

[Алексей++]

ещё одна жуткая подстава (тут транзакция не используется):

alter table T add F1 SMALLINT default 0
или даже так
alter table T add F1 SMALLINT default 0 not null

в таблице появляется поле, заполненное NULL. Его можно, конечно, отдельно заполнить после создания (так и приходится), но это же неправильно что-то

[RXL]

Леш, ALTER TABLE относится к DDL и в транзакциях не участвует. Соотв., транзакцию надо открывать после.
То, что у тебя получилось - видимо кривизна FB.
Попробуй через DEFAULT.

Код: (SQL)

ALTER TABLE T
  ADD E1 SMALLINT DEFAULT NULL
  ADD E2 SMALLINT DEFAULT 10
  ADD E3 SMALLINT;

[Алексей++]

так ведь не ставиться из дефолта во вновь созданное поле - смотри пост 12 Придётся при загрузке более тщательно на null проверять

[RXL]

Значить FB очень далека от стандартов. Нужно изучать ее особенности.

[McZim]

В некоторых навороченных СУБД все же их реализуют - в Оракл встречал вложенные.

ты имеешь ввиду автономные тразакции или что то другое?

[RXL]

McZim, их самых.