Назначение параметров запросу содержащемуся в SQL файле

← →
Тучудище (2005-05-24 08:31) [0]

Доброго времени суток уважаемые мастера!
Дело такое:
Есть некий файл Procedure.sql
Который содержит следующий запрос
SELECT ....... WHERE DateDoc BETWEEN :Param1 AND :Param2....
хотелось бы узнать, существует ли возможность назначить каким либо образом из Delphi эти самые :Param1 и :Param2
Заранее спасибо за ответ!

← →
DenK_vrtz © (2005-05-24 08:37) [1]

см. TParams

← →
Тучудище (2005-05-24 08:42) [2]

В самой программе св-во SQL у TQuery Выглядит так SELECT * FROM "Procedure.sql" так каким образом все таки можно этому Procedure.sql передать :Param1 и :Param2 на счет TParams понятно... но где??????

← →
DenK_vrtz © (2005-05-24 08:53) [3]

>но где??????

у TQuery свойство Params

← →
Тучудище (2005-05-24 09:00) [4]

Может я не догоняю что то, но каким образом в TQuery.Params могут попасть параметры из Procedure.SQL ведь сам TQuery.SQL имеет вид SELECT * FROM "Procedure.sql"...???

← →
atruhin © (2005-05-24 09:07) [5]

Сделай Prepare тогда Query распарсит файл и создаст параметры

← →
Sergey13 © (2005-05-24 09:15) [6]

Что за Procedure.sql? Какого он формата? Сколько в нем записей/команд?
Если ты делаешь SELECT * FROM "Procedure.sql" то стало быть потом идет выполнение содержащихся в файле запросов? Вот на этом этапе и надо присваивать значения параметрам.
Только нафига это все я не понял? Записей в Procedure.sql и количество параметров в них всегда одинаково?

← →
Тучудище (2005-05-24 09:29) [7]

Вот текст Procedure.sql

SELECT
Nomklat,
Sum(PrihRash) AS DebetCredit
FROM
PrihRash
WHERE
DateDoc BETWEEN :Param1 AND :Param2
GROUP BY Nomklat HAVING Sum (PrihRash)<>0

UNION ALL

SELECT
Nomklat,
Sum(Ostatok) AS DebetCredit
FROM
POstatki
WHERE
ActualDate:=Param1;
GROUP BY Nomklat HAVING Sum (Ostatok)<>0

Далее я вызываю пытаюсь выполнить запрос вида
SELECT Nomklat, SUM(DebetCredit) AS OstatokNaKonetz
FROM "Procedure.sql"
GROUP BY Nomklat HAVING SUM(DebetCredit)<>0
Собственно все замечательно, только вопрос стоит в том как передать этому Procedure.SQL Param1 и Param2

[5] спасибо за совет попробовал, но в момент TQuery.Prepare уже выдается сообщение "Parameter not set in query string"

← →
Тучудище (2005-05-24 09:32) [8]

[6]
Количество команд зашито жестко
Количество данных может изменяться
Делается все это для того, чтобы избежать(как мне кажется) лишних телодвижений с количеством запросов и сложных алгоритмов обработки данных

← →
Sergey13 © (2005-05-24 09:35) [9]

2[7] Тучудище (24.05.05 09:29)
Ты поступаешь в корне неправильно. Выкинь нафиг свой Procedure.sql - это тупик.

← →
Virgo_Style © (2005-05-24 09:36) [10]

Тучудище (24.05.05 9:32) [8]

А если сделать TQuery.SQL.LoadFromFile("procedure.sql"), а потом работать с TQuery.Params?

← →
msguns © (2005-05-24 09:37) [11]

А нельзя так:

with Query1 do
try
SQL.LoadFromFile("Procedure.sql");
Params[0].As... :=
Params[1].As... :=
Open;
except
ShowMessage("Shos probzdilo u datskomu korolivstvi");
end;

← →
ЮЮ © (2005-05-24 09:39) [12]

Procedure.sql - текстовый файл. Запиши его м нужными значениями, не параметрами.
Если клиент многопользовательский, то
1) уникальные имена для sql-файлов
2) + локальная БД и гетерогенные запросы

← →
ЮЮ © (2005-05-24 09:41) [13]

>[9] - [11]
Это подзапрос, а не полный запрос

← →
Sergey13 © (2005-05-24 09:41) [14]

Да у него ошибка не тут, а в
Далее я вызываю пытаюсь выполнить запрос вида SELECT Nomklat, SUM(DebetCredit) AS OstatokNaKonetz FROM "Procedure.sql" GROUP BY Nomklat HAVING SUM(DebetCredit)<>0

← →
msguns © (2005-05-24 09:48) [15]

А что, биде умеет работать с запросами
SELECT FROM (SELECT) ?

← →
Anatoly Podgoretsky © (2005-05-24 09:50) [16]

Через *.SQL

← →
ЮЮ © (2005-05-24 09:51) [17]

>Sergey13 © (24.05.05 09:41) [14]
и где ты тут ошибку видишь?

А вот параметры в запросе "Procedure.sql" использовать нельзя, т.к. текст должен содержать SQL предложение, а параметры - это уже фича от TQuery

← →
Тучудище (2005-05-24 09:53) [18]

[11] мне нужно получить результат запроса содержащегося в Procedure.sql и , чтобы не обрабатываеть его по тупому через
While not eof.... бла бла бла Next; выполнить к этому результату еще один запрос, делать результаты запроса permanent нет ни желания ни времени возиться с этим....

To all:
Может подскажите какой нибудь другой вариант?
Скажу что нужно,
1)Выполнить запрос № 1 из [7]
2)Обработать результаты запроса №1 запросом №2 из [7]
вот по сути и все...

← →
Anatoly Podgoretsky © (2005-05-24 09:57) [19]

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

По сути у тебя получается запрос из временной таблицы, которая формируется вне рамок твоего приложения движком БДЕ.

← →
Тучудище (2005-05-24 09:58) [20]

Честно сказать, не проблема мне зашить этот запрос в таком виде как он должен быть, т.е. вместо Param1 и Param2 подставить конкретные числа... т.е. даты какая к черту разница, опасаюсь следующего
1) Поскольку доступ к БД многопользовательский, возможны колизии при обращении к этому файло...(доступ к данному механизму будет осуществлятся достаточно часто)
2) Возиться с разными именами файлов следить за уникальностью и т.п. ну честно ну ГЕМОРОЙ, должно быть простое решение суть в том что я пока не чую какое......

← →
Anatoly Podgoretsky © (2005-05-24 10:00) [21]

Ни каких колизий если этот файл будет на локальной машине. Соответственно пункт 2 исчезает.

← →
Виталий Панасенко (2005-05-24 10:02) [22]

1) Выполнить запрос №1
1.1) Определить тип(имена (не очень существенно)) полей, создать ВРЕМЕННУЮ таблицу с аналогичной структурой. Перегнать данные из запроса в таблицу
2)Обработать временную таблицу запросом №2

← →
Тучудище (2005-05-24 10:18) [23]

Вот в принципе суть проблемы может я и не оттуда начал,
Данный запрос
SELECT
Nomklat,
Sum(PrihRash) AS DebetCredit
FROM
PrihRash
WHERE
DateDoc BETWEEN :Param1 AND :Param2
GROUP BY Nomklat HAVING Sum (PrihRash)<>0

UNION ALL

SELECT
Nomklat,
Sum(Ostatok) AS DebetCredit
FROM
POstatki
WHERE
ActualDate:=Param1;
GROUP BY Nomklat HAVING Sum (Ostatok)<>0
возвращает именно в LOCAL SQL такую белеберду
я пробовал исполнять его на InterBase и MySQL все работает ок
возвращаемый набор данных
Tovar DebetCredit
1 70
123 60
132 90
500 2
700 6
При исполнении его же в Local SQL я получаю что то вроде
Tovar DebetCredit
1 100
1 -30
123 60
132 90
500 4
500 -2
700 6
Я думаю суть ясна... вот что конкретно побудило меня искать извращенные пути решения проблемы.... может кто то подскажет по каим принципам Local SQL делает UNION

← →
Sergey13 © (2005-05-24 10:37) [24]

2[17] ЮЮ © (24.05.05 09:51)
>и где ты тут ошибку видишь?
А можно селектить текст запроса?

← →
Val © (2005-05-24 10:44) [25]

>[24] Sergey13 © (24.05.05 10:37)
? см. local views в Local SQL Help.

> автору
лучший выход - действительно динамический sql.

← →
msguns © (2005-05-24 10:56) [26]

>Тучудище (24.05.05 10:18) [23]

Блин, до меня дошло !!!
Это он считает текущие остатки по складу. Как сумма сальдо на начало+движение.
Во-первых, и биде, и мускул возвращают правильные результаты, просто второй по умолчанию использует предикат DISTINCT, а второй - нет.
Во-вторых, ведь то же самое можно получить одним запросом безо всякого UNION, который в биде порождает парные записи.
В-третьих, вопрос: а зачем это надо-то ? А если нет таблицы текущих остатков (что при такой системе было бы разумно предположить), то как и где задается время остатка, в смысле точка сальдо (месяц-год, скорее всего) ?

ИМХО, что-то нездоровым запахло ;))

← →
Anatoly Podgoretsky © (2005-05-24 10:59) [27]

Виталий Панасенко (24.05.05 10:02) [22]
Именно это и делается с использованием файла *.SQL только автоматически.

← →
Sergey13 © (2005-05-24 11:01) [28]

2[25] Val © (24.05.05 10:44)
>? см. local views в Local SQL Help.
Хм. Действительно. Не знал. Лоханулся. Сори.

← →
msguns © (2005-05-24 11:03) [29]

И еще в-четвертых: считается только кол-во ? Суммы джидаев не интересуют - не мелочны ?
В-пятых: все ж-таки неясно совершенно с этой загадочной таблицей остатков. Насколько я понял, она нужна для ускорения выполнения запросов подсчета кол-ва (сумм). Но почему в ней нет множественности по принципу сальдо по товару: Месяц: кол-во, сумма.
В шестых: а если по одному товару были разные приходы по разным учетным ценам и реализации по разныи отпускным ? Хотя, это уже суммовой учет, который, похоже, не для джидаев ;))

← →
Тучудище (2005-05-24 11:05) [30]

Поясню схему систему остатков реализую 2 таблицами
таблица 1:
Actions
Nomklat(Номенклатурник)
DebCred(Количество прихода расхода принимает значение -число +Число)
DateAct(Дата возникновения движения)
ну и некоторая служебная информация вроде тип документа и Ид документа
Таблица 2:
Period
Содержит
Nomklat(Номенклатурник)
DebCred(Количество остатка на конец периода)
Period - Это дата начала следующего месяца(01.XX.XX)
Что хочу от запроса, вынуть остаток на начало месяца
Прибавить к нему обороты за дату с 01.XX.XX по КонецМесяца.XX.XX
Тем самым вывести итог на 01.XX+1.XX но запрос порождает результаты о которых я говорил в [23] в следствии чего получаем на конец месяца какую то (извините) шнягу вместо путевых остатков не равных 0

← →
msguns © (2005-05-24 11:06) [31]

>Sergey13 © (24.05.05 10:37) [24]
>А можно селектить текст запроса?

>Sergey13 © (24.05.05 11:01) [28]
>Хм. Действительно. Не знал. Лоханулся. Сори.

См. [15],[16]

ЗЫ. Невозможность конструкции SELECT FROM SELECT лично у меня сильно подорвало авторитет IB, не говоря уж о биде ;)

← →
Тучудище (2005-05-24 11:10) [32]

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

← →
Anatoly Podgoretsky © (2005-05-24 11:10) [33]

БДЕ по крайней мере дает хотя бы обходной путь, но и от него не следовало ожидать многого, это все таки не БД, а движок, а то что в него включили серверный интерпритатор, то это только плюс.
А вот на сервера имеет смысл обижаться.

← →
msguns © (2005-05-24 11:12) [34]

>Тучудище (24.05.05 11:05) [30]

Как я понял, таблица "Actions" - это детал к документам, т.е. фактически фактура, да ? Т.е. приходы и расходы всех типов (в т.ч. возвраты, перемещения, списания и т.п.) - все "в куче" ?
Ну да ладненько.
Таблица "Period" является фактически деталом к номенклатурнику, период - лишь ее уник. ключ ?
Если так, то запрос-сабж по сути своей неверный, т.к. "опирается" на документы, а не на товар, что приведет к неполному результату выборок,- в сумму не попадет товар, не двигавшийся в течение указанного периода.

← →
msguns © (2005-05-24 11:14) [35]

>Тучудище (24.05.05 11:10) [32]
>суммовой учет не нужен абсолютно, учет ведеться только количественный,

Это кто так сказал - кладовщик Сеня ? Или уборщица Маша ? Или сторож Сан Саныч.
Глупости. Причем вовсе не ИМХО.

← →
Тучудище (2005-05-24 11:19) [36]

[34]
Если товар не двигался за этот период то его остаток есть на начало месяца в любом случае он попадает в итоги на конец месяца

Простой пример в этом месяце пришел товар 10 кол-вом 20
Остаток на конец периода 20
след месяц движений по товару 10 нет остаток на начало 20
получив остаток на начало периода прибавив обороты на конец получим остаток по товару 10 20 едениц.... он ползет из месяца в месяц....

Да, (actions) это детал по документам, но не фактура а абсолютно отдельная таблица (что то вроде регистра в 1Ц) при записи документа пользователем все необходимые данные по движениям добавляются в эту таблицу

← →
Тучудище (2005-05-24 11:21) [37]

[35]
Постановка задачи именно такая что суммовой учет никому не нужен

← →
ANB © (2005-05-24 11:30) [38]

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

← →
Johnmen © (2005-05-24 11:35) [39]

>msguns © (24.05.05 11:06) [31]
>ЗЫ. Невозможность конструкции SELECT FROM SELECT лично у меня
>сильно подорвало авторитет IB, не говоря уж о биде ;)

Всегда есть обходные пути. Да и в FB2 она уже появилась.

← →
Тучудище (2005-05-24 11:37) [40]

Люди... собственно... чего с запросом то делать??? запрос левый или Local SQL левый???

← →
msguns © (2005-05-24 11:43) [41]

>Тучудище (24.05.05 11:19) [36]
>он ползет из месяца в месяц....

Во-во. При наличие неликвида (т.е.остатков, которые годами торчат, пока их не спишут или не сбагрят по дешевке) таких "пустых" записей в базе будет великое множество - см.ANB © (24.05.05 11:30) [38]
Что через какое-то время приведет к разбуханию таблиц и жутким тормозам.
Более того, для торговли, например, в опте, где большой ассортимент и офигенная оборачиваемость товара, КПД от такой базы будет крайне низкий. Т.е. такая система хранения и подсчета остатков есть нерациональная как минимум.

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

← →
ЮЮ © (2005-05-24 11:43) [42]

см.[12] 2)
Кладешь ещё один TDataBase, его даже и настраивать особо не надо, только DataBaseName = local, т.е. та же папка где и ехе(если он локально лежит), или Alias ещё один сделай.

Теперь можешь делать гетерогенные запросы:

SELECT
Nomklat,
Sum(PrihRash) AS DebetCredit
FROM
PrihRash
WHERE
DateDoc BETWEEN :Param1 AND :Param2
GROUP BY Nomklat HAVING Sum (PrihRash)<>0

UNION ALL

SELECT
Nomklat,
Sum(Ostatok) AS DebetCredit
FROM
POstatki
WHERE
ActualDate:=Param1;
GROUP BY Nomklat HAVING Sum (Ostatok)<>0
INTO ":local:temp"

или пару запросов, если temp.db нужной структуры существует и лежит в local
DELETE FROM ":local:temp"
INSER INTO ":local:temp"
SELECT ... и далее по тексту

В запросах можешь исользовать одновременно таблицы основной и локальной БД

← →
msguns © (2005-05-24 11:51) [43]

>Johnmen © (24.05.05 11:35) [39]
>Всегда есть обходные пути.

Да, но очень неудобно иногда по запросу, например
SELECT <много разных полей и выражений> FROM <куча всяких таблиц> WHERE <до фига условий и параметров>
построить запрос, для получения агрегатов по некоторым полям

>Да и в FB2 она уже появилась.
Слышал-слышал. Однако писать приложения (запросы) в расчете, что у клиента стоИт именно 2-й берд ?

>Тучудище (24.05.05 11:37) [40]
>Люди... собственно... чего с запросом то делать??? запрос левый или Local SQL левый???

Сказано ж было:
1.рисовать запрос динамически.
2.создавать и юзать временную таблицу

>ЮЮ © (24.05.05 11:43) [42]

В Local SQL INTO нетути.

← →
Тучудище (2005-05-24 11:53) [44]

[41] Задача такова, есть некая транспортная компания, которая перевозит грузы(легковые автомобили), собственнику фиолетово сколько эти грузы стоят, ему интересно сколько у нас этого груза на какой площадке и кому он пренадлежит, торговля тут свосем не при чем

← →
ЮЮ © (2005-05-24 12:02) [45]

>В Local SQL INTO нетути.
зато есть
DELETE FROM
и
INSERT INTO ... SELECT ...

← →
Тучудище (2005-05-24 12:04) [46]

В Local SQL INTO нетути.
есть немного другая конструкция INSERT INTO .... SELECT FROM ....
по поводу временных таблиц думал... долго и упорно...
с таким же успехом можно сделать и DELETE запрос из той таблицы где считаются остатки на начало/конец периода... ИМХО

>Тучудище (24.05.05 11:53) [44]
>собственнику фиолетово сколько эти грузы стоят, ему интересно сколько у нас этого груза на какой площадке и кому он пренадлежит, торговля тут свосем не при чем

Неужели так-таки и фиолетово ?

Если перевозка, то причем здесь остатки (тем более сальдовые) и что такое номенклатура, если сущность груза никому "не интересна" и все можно мерить простым кол0вом этого самого "груза" ?

ИМХО, надо вести учет не груза, а транспорта. А еще точнее ТТН (товаро-транспортных накладных), в которых есть исчерпывающая инфа и о времени, и о грузе.
Однако, больших объемов данных в такой конторе, имхо, быть не должно. Сколько автомобилей заняты перевозкой ?

>msguns © (24.05.05 12:09) [48]
а это что?
INSER INTO ":local:temp"
SELECT ... и далее по тексту

К тому же и у автора был самый примитивны способ использования подзапроса :)

← →
Тучудище (2005-05-24 12:26) [50]

[47]
около 190 автомобилей, порядка 4000 в месяц перевозится, поясню зачем остатки, основным заказчиком является АВТОВАЗ, и ему страсть как интересно что творится у перевозчиков, т.к. там есть система штрафов и т.д. и т.п. поэтому и внедряю такую систему... я кстати уже нашел решение и воплотил его в жизнь получилось быстро и без наворотов излишних всем спасибо

[25] Val © (24.05.05 10:44)
> ? см. local views в Local SQL Help.

Интересно. Но вот вопрос, если это подобие вьюх в локал скуле, то, причем здесь параметры? Разве бывают вьюхи с параметрами?

← →
Тучудище (2005-05-24 12:35) [52]

view в Local SQL это QBE(Query By Example) файлы

[50] Тучудище (24.05.05 12:26)
А почему выбор пал именно на парадокс? Тоже интересно. :) Вроде, на ВАЗе и без того зоопарка хватает, от ФоксПро до Оракла, и все купленное.

Тучудище (24.05.05 12:35) [52]
Ошибаешься, просто кроме текстовых .SQL файлов local SQL позволяет использовать также и QBE файлы, только создавать их нужно в Парадоксе.

>ЮЮ © (24.05.05 12:16) [49]
>а это что?
>INSER INTO ":local:temp"

А ентот temp кто создаст, Чапаев ?

Правда в BDE есть такие неявные таблицы как Answer, но создаются они не TQuery ;)

>Тучудище (24.05.05 12:26) [50]
около 190 автомобилей, порядка 4000 в месяц перевозится, поясню зачем остатки, основным заказчиком является АВТОВАЗ, и ему страсть как интересно что творится у перевозчиков, т.к. там есть система штрафов и т.д. и т.п. поэтому и внедряю такую систему...

Все равно не понял: кто на ком стоял (с)?
В смысле кто что перевозит ? Т.е. автотранспорт т.н. Собственника перевозит грузы (запчасти ?) для ВАЗа или перегоняет тачки ? Если второе, то тачки с грузом ? Не врубился, извини за тупость.

>я кстати уже нашел решение и воплотил его в жизнь получилось быстро и без наворотов излишних всем спасибо

Если нашел, то че приходил ?

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

← →
Тучудище (2005-05-24 13:30) [56]

[55] Перевозка 4000 легковых автомобилей в месяц осуществляется автовозвми собственика по заказу ОАО "Автоваз". решил я и без SQL файла немного поэкспрементировав с запросами. Под наваротами понимал загаулистую систему с переброскай во временные таблицы и т.д. и т.п.
По поводу хранения текстов запросов в текстовиках, у меня все отчеты так хранятся.
[50] Мы к Вазовскому зоопарку не относимся хотя я не спорю там работают все типы СУБД! только вот у них правая нога не знает что делает левая %-)
[55] Спрашивал по тому, что не мог допереть возможно ли при хранении запроса в файле ссылаться на его параметры, с толку сбило сообщение об ошибке что якобы параметры не установлены, что сподвигнуло к следующему "Раз не установлены значит как то можно" ------ бамбарбия---киргуду :-)
[50] Система написана года 3 назад и жалоб на нее нет, так что не вижу смысла пока переходить на что то другое.(Конечно скуль сервер это рулез и вообще масса вкусностей, но мне денег на него ни кто не даст это раз, сервер под него ни кто не купит это два)

Всем огромное спасибо за ответы!

← →
Тучудище (2005-05-24 13:32) [57]

Да вспомнил как то мне попалась инфа в руки о ХП в парадоксе скорее всего она меня и сбила с толку... при чем конкретно! :-)

>Тучудище (24.05.05 13:30) [56]
>скуль сервер это рулез и вообще масса вкусностей, но мне денег на него ни кто не даст это раз, сервер под него ни кто не купит это два)

Есть масса бесплатных типа IB/FB - это три ;)

Удачи !

[56] Тучудище (24.05.05 13:30)
> но мне денег на него ни кто не даст это раз, сервер под
> него ни кто не купит это два

ну, вообще-то есть и бесплатные скуль-сервера, от той-же Микрософт, например. И не так уж много они ресурсов жрут. Просто, я смотрю, ты работаешь с Парадоксом так-же как и с Скуль-сервером. Выносишь запросы в текстовые файлы - все равно, что бизнес-логику на сервер выносить в те-же вьюхи и ХП. :)

>Тучудище (24.05.05 13:32) [57]
>Да вспомнил как то мне попалась инфа в руки о ХП в парадоксе скорее всего она меня и сбила с толку... при чем конкретно! :-)

Там (в BDE) еще есть понятие транзакции ! Так вот, самое удивительное, что и транзакции, и ХП и все остальное - все это соответствует действительности. Но при одном условии,- если через BDE юзаются скуль-серверы, поддерживающие эти фичи.
Для парадокса, дибэйза и прочих локалок это лишь фикция.

Хранимые не фикция, по крайней мере для дБейс, но реализовать очень сложно. Трансакции фикция.

← →
Тучудище (2005-05-25 07:22) [62]

Я сделаю проще, возьму MSDE, возьму ADO, и сделаю по людски, один черт придется рано или поздно переносить на Client/Server архитектруру!!! лучше раньше чем позже! :-)

[62] Тучудище (25.05.05 07:22)
маладец :)

Тучудище (25.05.05 07:22) [62]
Правильно

>Тучудище (25.05.05 07:22) [62]

Верною дорогою идете, товарищ ! Особенно если еще вместо парадокс выберите что-нибудь серверное (например мсскуль)

Желаю побыстрее из тойчудища превратиться в этукрасавицу ;)

Назначение параметров запросу содержащемуся в SQL файле Найти похожие ветки