Hi Crip!

И чем же ADO лучше ODBC?

2 Sergej_S

Забудь про FetchAsNeeded с разделяемыми соединениями. Впрочем лучше ВООБЩЕ забудь про этот механизм - вынимай только самые необходимые записи, причём ВСЕ сразу. Это проще и надёжнее.
P.S. Почитай хелп на предмет того что есть Connection handle, а что - Statement handle. Имея всего одно соединение, тем не менее каждому CAD давай свой statement handle - через SQLCONNECT(m.gnMainHandle) - и не забывай закрывать эти хендлы при уничтожении CAD - наличие всего одного живого хендла (того что m.gnMainHandle) более чем достаточно, дабы соединение не разрывалось.

Posted via ActualForum NNTP Server 1.2

Hi Sergej_S!

> А надо ли для CAD.DeleteCmdDataSource...
Нет не надо.

Про тонкости реализации ODBC я тебе не расскажу - если интересно - бери MSDN и читай - весьма обширная тема. К фоксу это прямого отношения не имеет - просто ДО VFP8 судя по всему фокс не мог создавать >1 statement-а на коннект...

2 Crip

1) Поддерживается, но AFAIK не для любого драйвера - см. вкладку в диалоге ODBC администратора.
2) Нечего слать такие команды! Клиентские транзакции в ODBC организуется совсем иными средствами - впрочем как и в ADO. Из фокса ручная транзакционная поддержка на ODBC коннект включается через SQLSETPROP(...,"Transactions", DB_TRANS_MANUAL) где константа = 2. После этого приобретают смысл функции SQLCOMMIT(...) и SQLROLLBACK(...) Как такового, понятия "открытие транзакции" нету в промышленных СУБД. Там транзакция ВСЕГДА открыта - т.е. там имеют значение лишь точки сохранения/отката, и возможно SAVEPOINT-ы (далёкие аналоги вложенных транзакций). Это лишь фокс позволяет сделать что-то с данными вообще без транзакции :)
3) Насчёт "внешних приложений" я сомневаюсь - разве что если твоё приложение это Application-сервер... В прочих случаях наверное проще организовать обмен через XML. НО главный аргумент тут в том, что для фоксовых контролов (грид, листбокс, комбобокс) использование ADO существенно затрудняет программирование. Теперь простой вопрос - как ты думаешь, чем пользуется большинство фоксовых программистов - родными контролами, или разными там ActiveX-овыми?

P.S. О том, что более навороченный ADO работает заметно медленнее чем ODBC, я и вовсе не говорю. Конечно проверять надо не время "открытия RS" а полное время - от установления соединения (ну или по минимуму - от попытки открытия RS/выполнения SQLEXEC()) до ПОЛНОГО извлечения запрошенных данных.

Posted via ActualForum NNTP Server 1.2

Hi Crip!

ms-help://MS.MSDNQTR.2004JUL.1033/odbc/htm/odbctransactions_in_odbc.htm

Читать до прояснения (возможно начиная с родительской статьи, а то нехорошие подозрения закрадываются...) Никаких батчей не требуется, всё можно откатить в любой момент (что не было ЯВНО сохранено через АПИ функцию SQLEndTran, которую видимо и дёргает фоксовый SQLCOMMIT()). К MS SQL прямого отношения это не имеет - ссылка на его персональную настройку IMHO некорректна.

Posted via ActualForum NNTP Server 1.2

Hi Crip!

Вообще-то я говорил о ВЫКЛЮЧЕНИИ этого режима, и перехода к ЯВНОМУ
управлению транзакциями.
Да, в ODBC нету возможности ЯВНО НАЧАТЬ транзакцию - однако он САМ её
начинает при отсылке любой команды - при этом позволяя уже ЯВНО подтвердить
или откатить изменения.
Давай поступим проще - ты набросай сценарий, когда ODBC транзакции не могут
сделать чего-то, а ADO транзакция (которая и отличается то только тем, что
её нужно ЯВНО НАЧАТЬ) может. Я вот сейчас например не вижу таких сценариев.

> P.S. У ADO есть еще одно приемущество - легкость использования серверных
> курсоров, которые фокс вообще не поддерживает.

Вообще-то фокс в принципе не может поддерживать или не поддерживать это. Он
пользуется для доступа к внешним данным НЕ СВОИМ движком - так что лишь то
что реализовано в использованной прослойке и будет доступно. При работе
через ADO фоксу доступны и серверные и клиентские курсоры (также с любым
типом доступа) - конечно если выбранный OLE DB провайдер (и соответственно
сам сервер) это поддерживает.
Кстати говоря, это преимущество имеет смысл только в случае НЕ использования
фоксовых курсоров - ибо если мы всё-же хотим использовать фоксовый курсор,
то придётся извлекать ВСЕ записи и смысла в серверном размещении данных не
остаётся. А извлечь данные придётся, если захотим использовать фоксовый
грид, лист или комбобокс...

P.S. Создаётся впечатление, что ты считаешь что ODBC "встроен" в фокс -
однако это не совсем так - это такая-же "внешняя" по отношению к нему
технология как и ADO. Просто в фоксе существует сравнительно неплохой
ODBC-клиент, который делает "прозрачной" работу с ODBC.

Posted via ActualForum NNTP Server 1.2

Hi Crip!

> Пример? Лучший пример это вложенные транзакции.

IMHO это ЕДИНСТВЕННЫЙ пример, а если учитывать то КАК реализуются (и
реализуются ли ВООБЩЕ) вложенные транзакции в разных СУБД, то вопрос
отпадает сам собой...
Меня в своё время весьма удивила логика работы Savepoint-ов в MS SQL, не
говоря уж о вложенных транзакциях - которые по сути НИЧЕГО не делают...

Posted via ActualForum NNTP Server 1.2

Hi Crip!

Это совсем другой вопрос! Просто ты говорил что "нельзя и всё" - а это на самом деле не совсем так.

Кстати говоря насчёт батчей:

When a batch is executed in autocommit mode, two things are possible. The entire batch can be treated as an autocommitable unit, or each statement in a batch is treated as an autocommitable unit. Certain data sources can support both these behaviors and may provide a way of choosing one or the other. It is driver-defined whether a batch is treated as an autocommitable unit or whether each individual statement within the batch is autocommitable

Так что то что сработало сейчас для MS SQL может не сработать завтра, или для другого SQL сервера...

Если внимательно почитать MSDN, то явно видно, что по своим транзакционным возможностям ODBC и OLE DB практически идентичны (ну разве что их Scope различается - для ODBC это коннекция, для OLE DB это Session). Вот цитата про OLE DB транзакции - как видишь практически идентично ODBC.

A session can be inside or outside of a transaction at any point in time. When a session is created, it is outside of a transaction, and all work done under the scope of that session is immediately committed on each method call. This is referred to as the autocommit or implicit commit mode.

If the provider supports transactions, the session supports the ITransactionLocal interface. Calling ITransactionLocal::StartTransaction begins a transaction on the session. ITransactionLocal inherits from the ITransaction interface, which supports the Commit and Abort methods. When a session enters a transaction, all work done by the session, its command and rowsets, are part of that transaction.

2 Aleksey-K

Есть в MSDN противоречивости в данной части. С одной стороны:

ODBC applications should not mix managing transactions through the ODBC autocommit options with calling the Transact-SQL transaction statements. If an application does this, it could generate undetermined results. The application should manage transactions in one of the following ways:
- Use SQLSetConnectOption to set the ODBC autocommit modes.
- Use Transact-SQL statements, such as BEGIN TRANSACTION. (The SQLSetConnectOption should be left at its default setting of autocommit on.)

А с другой стороны

ODBC applications should not use Transact-SQL transaction statements (such as BEGIN TRANSACTION, COMMIT TRANSACTION, ROLLBACK TRANSACTION) because this can result in indeterminate behavior in the driver. An ODBC application should either:
Run in autocommit mode and not use any transaction management functions or statements.
-or-
Run in manual-commit mode and use the ODBC SQLEndTran function to either commit or roll back transactions.

P.S. Кстати натолкнулся на интересную статью - MSKB # 177138 INFO: Nested Transactions Not Available in ODBC/OLE DB/ADO
В ней говорится что единственный способ поиметь вложенные транзакции - это использовать DAO с MS Jet - конечно статья не новая, и возможно с того времени появились и другие OLE DB провайдеры (поддерживающие вложенные транзакции)...

Posted via ActualForum NNTP Server 1.2