Таблица Paradox и установка программы на новый пк

← →
Loginov Dmitry © (2008-05-30 15:34) [80]

А в транзакциях с парадоксом кто-нибудь работал? Тоже глюк есть нехилый (больше года отлавливал его), из-за которого их опасно откатывать (в некоторых случаях может половина изменений откатиться, а половина - приняться).

← →
MsGuns © (2008-05-30 15:46) [81]

Парадокс знает что-то о транзакциях ?
Нсколько я знаю вся его "транзакциозность" заключается в механизме буферизации "чиста на клиенте". Откат запроса (не говоря уже о нескольких) - это вообще фантастика ;)

← →
Loginov Dmitry © (2008-05-30 16:08) [82]

> Парадокс знает что-то о транзакциях ?

Согласно документации, что-то знает :)

> Нсколько я знаю вся его "транзакциозность" заключается в
> механизме буферизации "чиста на клиенте".

В нашей системе транзакционность используется при проведении тех или иных документов. Чаще всего откатывает нормально ;)

> Откат запроса (не говоря уже о нескольких) - это вообще
> фантастика ;)

Но формально-то он есть! :)

← →
MsGuns © (2008-05-30 16:13) [83]

Нетути ! С чего Вы взяли, что есть ? Не с того ли что в TDataBase есть методы с этим волшебным словом ? Так то враки все ;)

← →
Reindeer Moss Eater © (2008-05-30 16:19) [84]

Вообще есть. И в книжках написано.

← →
Reindeer Moss Eater © (2008-05-30 16:26) [85]

"C:\Program Files\Common Files\Borland Shared\BDE\bde32.hlp"

http://img147.imageshack.us/img147/2084/transwp3.jpg

Transactions for Paradox, dBASE, FoxPro, and Access drivers (local transactions) enable you to roll back (revert) or commit updates to standard tables. This helps ensure that applications will perform updates in a consistent way.
.......

← →
MsGuns © (2008-05-30 16:32) [86]

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

← →
Loginov Dmitry © (2008-05-30 16:38) [87]

> Т.е. ты хочешь сказать, что я могу вложить в одну транзакцию
> два запроса на изменение в разных таблицах, выполнить эти
> запросы, а потом откатить, и новых записей не окажется в
> обеих таблицах ?

Именно! :)

← →
Loginov Dmitry © (2008-05-30 16:40) [88]

> Нетути ! С чего Вы взяли, что есть ? Не с того ли что в
> TDataBase есть методы с этим волшебным словом ? Так то враки
> все ;)

И кто еще писатель-то? ;)

← →
Ослик (2008-05-31 00:52) [89]

К теме ветки не имеет отношения, но показываю здесь, ибо здесь наиболее странная ситуация.
Опять начались проблемы с анкетами. У многих зарегистрированых пользователей по ссылке в @ открывается страница с ошибкой "Анкета не найдена", хотя если делать поиск анкет по нику, то у этого ника анкета есть и ее можно посмотреть.
А в этой ветке вообще весело.
Ник один и тот-же, Германн.
Но в [1] [13] анкеты нет, а в [15] [17] [20] уже есть, в [74] опять нет.
Соответственно и ссылки разные, там где нет анкет:
http://www.delphimaster.ru/cgi-bin/anketa.pl?id=1084974900
а там где есть:
http://www.delphimaster.ru/cgi-bin/anketa.pl?id=1191940992

← →
Германн © (2008-05-31 01:27) [90]

> Ослик (31.05.08 00:52) [89]

Ща проверим.

← →
Германн © (2008-05-31 01:31) [91]

Проверка №2

← →
Ослик (2008-05-31 01:32) [92]

Круто! :)
Как ты это делаешь? :)

← →
Германн © (2008-05-31 01:33) [93]

Это не проблема с анкетами. Это я обновил свою анкету только в основной оси на своём компутере. А в прочих (тестовых осях) не обновил. Прошу прощения.

← →
Ослик (2008-05-31 01:37) [94]

В смысле, в куках хранится не только имя, но и айдишник пользователя?

← →
Германн © (2008-05-31 01:45) [95]

> Ослик (31.05.08 01:37) [94]
>
> В смысле, в куках хранится не только имя, но и айдишник
> пользователя?
>

В смысле куки свои на осях.

← →
Ослик (2008-05-31 01:53) [96]

[95] Германн © (31.05.08 01:45)
Понял.
Просто, я думал, в куках только ник хранится, а движок форума по нику сам айдишник подставляет.

← →
Anatoly (2008-05-31 13:40) [97]

> Именно! :)

Наивный

← →
Loginov Dmitry © (2008-05-31 19:03) [98]

> > Именно! :)
>
> Наивный

В каком смысле? То есть я несколько лет использую транзакции в Парадоксе, а их нет? Так чтоли? Или имеется что-то другое ввиду?

← →
MsGuns © (2008-05-31 20:05) [99]

Из справки по Делфи:

Call StartTransaction to begin a new transaction against the database server.

У парадокса есть сервер ?

Просто подумайте сами, каким образом можно разруливать транзакциями в системе, где нет центрального механизма управления данными - только лишь посредством lck-файлов ? Не будет ли такой механизм подвержен, мегко говоря, постоянным крахам ?

← →
MsGuns © (2008-05-31 20:16) [100]

Очевидно, Вас ввело в заблуждение само наличие в компонентах BDE "транзакционных" методов. А они там есть просто потому, что BDE является универсальным движком, предназначенным работать с разными СУБД, в том числе и теми, которые знают и умеют работать с транзакциями (т.е. скл-серверы).

Другими словами, если Вы используете в приложении явное управление транзакциями, то оно будет "работать" только в том случае, если "сервер", т.е. получатель о обработчик скл-запросов, является собственно скл-сервером. В противном случае Вы получите либо муляж, либо эмуляж, т.е. искусственное подобие поддержки транзакций, которое возможно поддерживается некоторыми локальными "движками" (вроде Информикса, если мне не изменяет память).

Чтобы не спорить далее, я попробую привести Вам только один, но ИМХО убийственный довод против Вашей уверенности - если бде поддерживает транзакции для парадокса (а кроме него там некому поддерживать, ибо, повторяю еще раз, у парадокса нет сервера), то во-первых, почему эти самые транзакции не коммитятся и не откатываются автоматически при работе с БД типа STANDARD, как это делается во всех "нормальных" серверных системах ?, и во-вторых, почему парадоксовые базы так часто рушатся, в то время как "завалить" любой сервер вовсе не так просто ?

← →
Anatoly Podgoretsky © (2008-05-31 23:33) [101]

> Loginov Dmitry (30.05.2008 16:40:28) [88]

> For Paradox, local transactions can only be performed on tables with valid indexes. Data cannot be rolled back on Paradox tables that do not have indexes.
> Only a limited number of records can be locked and modified. With Paradox tables, you are limited to 255 records. With dBASE the limit is 100.

И еще не работает для удаления записей.

← →
Loginov Dmitry © (2008-06-01 01:04) [102]

> если бде поддерживает транзакции для парадокса (а кроме
> него там некому поддерживать, ибо, повторяю еще раз, у парадокса
> нет сервера)

Транзакциями для Парадокса рулит BDЕ, кто же еще.

> то во-первых, почему эти самые транзакции не коммитятся
> и не откатываются автоматически при работе с БД типа STANDARD,
> как это делается во всех "нормальных" серверных системах
> ?,

Там реализовано примерно следующим образом: После старта транзакции все измененные записи сразу пишутся в табличку. После этого они сразу доступны для чтения всем остальным. Но на них накладывается блокировка и остальные не могут эти записи редактировать. Если транзакцию не завершать, то будет "подтверждение". Вызов TDataBase.Commit практически ничего не делает, а вот если вызвать Rollback, то начнется последовательный откат всех изменений. Как раз Rollback в некоторых случаях глючит, откатывает "наполовину" :)

> убийственный довод против Вашей уверенности

А смысл? Я на практике с этим механизмом работаю, Вы же, не работая с них, уверяете что этого нет.

> With Paradox tables, you are limited to 255 records.

Лимит в 255 записей - это в лучшем случае. Если одну запись редактировать в двух наборах данных (два TQuery), то лимит окажется в 2 раза меньше.

> И еще не работает для удаления записей.

Работает.

← →
MsGuns © (2008-06-01 03:11) [103]

Все, что Вы говорите, действительно для ОДНОЙ таблицы. И только в тех пределах, что указано выше. И реализовано, как Вы верно заметили, самой бде непосредственно НА КЛИЕНТЕ. В лок-таблицах лишь делается отметка о том, что записи такие-то заблокированы (собственно для этого и нужны индексы - чтобы не держать всю запись целиком, а записывать только ее индекс) и не могут быть использованы другими пока тот, кто заблокировал, не подтвердит или не откатит. Но там нет САМИХ ЗАПИСЕЙ, ибо они "сохраняются" в кэшах на клиенте. И если клиент "зависнет" или отключится, то для всех остальных эти записи так и останутся заблокированы. До тех пор, пока "вручную" не прибить лок-файл. Естественно целиком. Так о каких транзакция тут речь ибо категорически не выполняется первое и самое главное условие транзакций - целостность, то есть либо все, либо ничего. А Вы все время твердите о каких-то половинчатых откатах, (называя это почему-то "глюком") - сами же и подтверждаете собственную неправоту ;)

Я же предлагал попытаться изменит ДВЕ таблицы ЗАПРОСАМИ, а не TTable. И посмотреть что получится если с клиента будет дан TDataBase.RollBack. А получится то, что никакого отката не произойдет. По простой причине, что ВДЕ, выполняя изменения ЗАПРОСАМИ, никаких кэшей на клиенте не держит и поэтому попросу "не поймет" команду на откат, просто проигнорирует ее молча.

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

← →
имя (2008-06-01 03:19) [104]

Удалено модератором

← →
Германн © (2008-06-01 03:31) [105]

Удалено модератором

← →
Loginov Dmitry © (2008-06-01 09:55) [106]

> И посмотреть что получится если с клиента будет дан TDataBase.RollBack.
> А получится то, что никакого отката не произойдет. По простой
> причине, что ВДЕ, выполняя изменения ЗАПРОСАМИ, никаких
> кэшей на клиенте не держит и поэтому попросу "не поймет"
> команду на откат, просто проигнорирует ее молча.

У меня 3-х звенка, обращение к базе выполняется через TRemoteDataModule, т.е. вся работа с базой осуществляется в пределах одного компьютера. В пределах одного компьютера транзакционность РАБОТАЕТ (независимо как были сделаны изменения - запросами или TTable)! Если не верите, так кто мешает проверить (для этого вполне достаточно SQL Explorer)?

Насчет сетевой базы - не проверял, но скорее всего и в этом случае транзакционность работает. Я проверю.

← →
Loginov Dmitry © (2008-06-01 10:30) [107]

Насчет сетевой базы: я не пойму, там по какому принципу блокировки работают :)
Информация о блокировках в NetDir записывается? По видимому так.
У меня первый комп не видит изменений, вносимых вторым компом, пока на втором не закроешь табличку.
Никаких сообщений о блокировках вообще нет.
Транзакции работают не поймешь как :)

Вывод: SQL Explorer не то средство, в которым делаются сетевые тесты :)

Придется для проверки делать тестовое приложение в Delphi с установкой NetDir :(

← →
Reindeer Moss Eater © (2008-06-01 11:51) [108]

Вопрос то был про существование транзакций вообще, а не про ограничения в их реализации на парадоксе. На поверку оказалось, что транзакции таки есть, хоть и есть ограничения.
Как и в случае "взрослых" дбмс они есть, хоть и меньше их там. (ограничений)

У парадокса есть сервер ?

Нет, нету. Все операции над парадоксом выполняют зеленые человечки с альфа-центавры.

Тест показал, что транзакционность работает одинаково - как на локальном компьютере, так и в сети.
Одновременно может быть запущено несколько транзакций, однако на измененные записи накладывается блокировка, и другие транзакции изменить эти записи уже не могут.
Чтобы тест заработал, пришлось выставить LOCAL SHARE=TRUE и указать сетевой каталог.

Тесты показали, что с LOCAL SHARE=FALSE парадоксу в сети вообще делать нечего, ибо никакие блокировки не срабатывают (независимо от NetDir). Транзакция при этом также правильно работать не может. Доходит до того, что у каждого клиента появляется собственная версия записи, и такой дурдом проявляется до тех пор, пока не завершишь все транзакции и не переоткроешь таблички у всех клиентов. Причем фактически принимается только транзакция, завершенная на компьютере с базой данных, а у остальных Commit срабатывает вхолостую. Так что там даже версионность поддерживается :о)

Как выражаются пользователи BDE: убить бы того, что придумал LOCAL SHARE=FALSE по умолчанию (с) :)

> Loginov Dmitry (01.06.2008 14:27:50) [110]

> Тесты показали, что с LOCAL SHARE=FALSE парадоксу в сети вообще делать нечего

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

> И на рабочей станции тоже, поскольку это еще больший источник
> проблем, вплоть до потери части базы.

У наших клиентов кстати по прежнему стоит LOCAL SHARE=FALSE. Раньше много проблем с этим было (таблички иногда программа не закрывала, а спустя несколько дней могла и зависнуть :)

Сейчас вроде устаканилось. Молимся, чтобы и дальше проблем не было =)

>Reindeer Moss Eater © (01.06.08 11:53) [109]
>>У парадокса есть сервер ?
>Нет, нету. Все операции над парадоксом выполняют зеленые человечки с альфа-центавры.

Вы, как и Loginov Dmitry ©, путаете кэширование и транзакции.
Что меня лично удивляет ;)

>Loginov Dmitry ©

Если Вы задумали сделать трехзвенку, т.е. "замкнуть" всех пользователей на некую программу - "сервер", которая будет "монопольно" работать с парадоксовой БД (по сути - трехзвенку), то Вы должны были позаботиться о том, чтобы этот сервер обеспечивал транзакционность. Причем сам, а не доверился бы при этом "глюкавому" (потому что не для того он проектировался) БДЕ. Т.е. всего навсего написать собственный механизм подтверждений-откатов, а также "разруливания" коллизий между конкурентами или,- иными словами,- полноценный блокировочник или версионник (в зависимости от организации хранения данных незакрытых транзакций). Судя же по Вашим постам, Вы и не думали об этом. В результате получился некий Мерс, снабженный двигателем от Москвича, а колесами от Запорожца. В результате он или не едет вовсе или едет только с горы ;)

и при чем здесь локальное кеширование?
терям ход собственных мыслей?

в связи с чем вообще возник вопрос есть ли у парадокса сервер?
после того, как в хелпе было прочитано про транзакции что де агаинст сервер бла-бла-блаю. После чего мсганс увидев слово "сервер" ухватился за него и стал спрашивать а где типа сервер, кто там вообще транзакции начинает заканчивает.

БДЕ начинает и заканчивает. Это и есть "сервер" парадокса.

> MsGuns (01.06.2008 18:25:54) [114]

Парадокс не зря парадоксом назвали, к нему много чего прикрутили под влиянием коньюктуры, а проблемы начались потом.

>Reindeer Moss Eater © (01.06.08 19:23) [115]
>после того, как в хелпе было прочитано про транзакции что де агаинст сервер бла-бла-блаю.

Текст про "универсальность" БДЕ пропустил ? Именно про работу его с серверами и намек в хелпе ;)

>БДЕ начинает и заканчивает. Это и есть "сервер" парадокса.

Что в твоем понимании есть "сервер" ?

И еще немного о парадоксе. Вообще-то Paradox появился несколько ранее BDE и существовал (как впрочем и существует и поныне) как СУБД, т.е. помимо самого формата была еще целая среда (в ДОСе), которая и была "сервером" в твоем понимании. Начиная с версии Paradox 4.0 эта самая среда вместо своего "сервера" использовала BDE.

Ты удивишься, но с тех пор технология работы с базами парадокс изменилась несущественно. Только вот что "родной" устаревший "сервер", что "сервер" под названием BDE как не имел ничего общего (кроме, конечно, своего прямого назначения) с SQL-серверами, так ничего и не имеет до сих пор. Все современные "примочки", в т.ч. и кореловские, позволяют работать с парадоксом как с "сервером" лишь в связке с "нормальными" скл-серверами (у Корела это Интербэйз)

По сути парадокс как БД ничем не отличается от дибэйза и являетя "локальной" БД со всеми ее атрибутами: таблицы и индесы в файлах, совместые "соглашения" для обеспечения совместной работы тоже в файлах, все "констрэинты" (если их можно так назвать относительно скл-серверов) тоже в файлах. А это уже на скл-сервер.

А может, мы путаемся в скл и файл-серверах ? Так это тоже разный жанр вообше-то ;)

знатный съезжальщик с темы.

Я так понял, что дискуссия плавно перетекла в толкучку "сам дурак" ?
Пора откланяться ?
Без проблем ;)

Таблица Paradox и установка программы на новый пк Найти похожие ветки