Работа с Paradox на сервере
У меня такой вопрос, возможно ли работать с таблицей парадокс хранимой на сервере(имено парадокс), осуществить програмным путём взятие из неё данных(по условию задачи программа делает это сама).
Почемуто у мну мало чего вышло, мб я не тот драйвер использую?
ЗАбыл добавить, что это необходимо сделать с помощью компанента ADOConnect
Подскажите плз...
Заранее спс.
Для makbeth: Как я понял не возможно просто подключить талюицу ч/з АдоКонект и работать с ней?
Насколько я знаю, да :rolleyes:
а собственно с чего вы это взяли? база данных парадокс (как и прочие файловые БД) может быть размещена на сервере, в расшаренной папке. И доступ к ней возможно дать без проблем. Это конечно не будет полноценным сервером - но работа нескольких (3-10) клиентов будет возможна, без особых проблем - особенно если проектировать программу с учетом данного ньюанса. Второй вариант решения проблемы - создание трехзвенки в которой пользователи работают не с базой непосредственно, а с серверным приложением - задача создания такого ПО не скажу что уж очень простая - но вполне решаема, тем более в делфи с использования RDM-модуля.
А разве с помощью ADO можно подцепить Paradox с другого сервака? Речь идет об этом. :rolleyes:
это будет полноценным файл-сервером ;) и это не есть фонтан, абсолютно. Согласен.
А смысл? Фактически, этот костыль - попытка превращения файл-севера в клиент-сервер. Не проще ли взять нормальную клиент-серверную СУБД? Тем более выбор большой...
тогда объясните что вы понимаете под "подцепить". Для АДО в целом абсолютно паралельно где будут находиться файлы (в конце концов - сетевые диски в системе существуют :) )- лишь бы к ним был доступ и система на которой они лежат поддерживала виндовский интерфейс (либо самба либо винда). Т.е. практически топикстартеру необходимо расшарить папку на какой либо машине, положить туда файлы баз и настроить нормально DNS на машине клиента (руками или программно). Прийдеться возможно повозиться с блокировками (на самбе по крайней мере) - но проблема вполне решаемая.
Согласен что решение далеко не ахти - но если база рабочая, и стоит задача обеспечения доступа нескольких пользователей в переходный период - то это тоже вариант.
Зачем это делать - хз. мы же не знаем какая задача стоит. Перенос фаловой базы на нормальный сервер - это задача как правило на неделю (при идеальных условиях), а если учесть что у автора возникают подобные вопросы - то и больше. В это время пользователи будут работать.
На самом деле, это можно сделать, но получиться такая вот связка: ADOConnection -> ADO -> Jet OLE DB -> ODBC -> Native BDE Driver :eek: -> *.db И нафих оно надо? :D
Для дальнейшего безгеморного перехода на полноценный SQL Server, поддерживающей работу через ADO, останется только указать нужный драйвер (можно вынести в настройки приложения), и работай с любым сервером.
На самом деле, это можно сделать, но получиться такая вот связка: ADOConnection -> ADO -> Jet OLE DB -> ODBC -> Native BDE Driver :eek: -> *.db И нафих оно надо? :D
Или мы не понимаем друг друга или вы плохо себе представляете ньюансы работы с базой данных АДО. Связка у вас получиться (при условии использовании технологии АДО) в любом случае. Для вас это новость?
Все что необходимо сделать вам - это сформировать следующую строку подключения
при условии что ваша папка подключена как сетевой диск Х - в чем проблема собственно?
Эту строку вы и должны прописать. И все заработает. Вопросы нафик оно надо или не нафик оно надо - не задавались - вопрос задан конкретно:
Почемуто у мну мало чего вышло, мб я не тот драйвер использую?
ЗАбыл добавить, что это необходимо сделать с помощью компанента ADOConnect
Мой ответ - да возможно. Как - я объяснил.
[QUOTE=oxotnik333]
Для дальнейшего безгеморного перехода на полноценный SQL Server, поддерживающей работу через ADO, останется только указать нужный драйвер (можно вынести в настройки приложения), и работай с любым сервером.
[/QUOTE]
Ну не так оно все просто как кажеться, к сожалению. Если уже переносить базу - то ее стоит модифицировать. Хотя... эт уже дело хозяйское - никто не мешает работать с сервером как и с файловой базой.
В топике по SQL не так давно меня просветили и убедили насчет скорости обычных запросов и ХП (разница в выполнении не существенна), основное преимущество ХП, триггеров и прочей лабуды в том что вся структура в одном месте сосредоточена.
По сему если у человека выполнялись запросы в файловом варианте то они будут выполняться и в серверном (выполнять будет уже сервер), модификация БД потребуется минимальная, даже вообще может все закончиться простой перекачкой данных из файлов в СУБД
ЗЫ: а если будут перелопачивать всю структуру БД под серверную, тогда многое в логике клиента менять придется
По сему если у человека выполнялись запросы в файловом варианте то они будут выполняться и в серверном (выполнять будет уже сервер), модификация БД потребуется минимальная, даже вообще может все закончиться простой перекачкой данных из файлов в СУБД
ЗЫ: а если будут перелопачивать всю структуру БД под серверную, тогда многое в логике клиента менять придется
Так себе представляю, что было бы, если бы топик подобного рода написал кто нибудь из топов автотранспортного предприятия (или строительной компании например):
В топике по тяжелым грузовым машинам меня убедили и просветили что в скорости маза-миксера и запорожца разница не существенна. Основное преимущество миксера - всякая лабуда - типа наличия бетономешалки. По сему бетон можно возить и на запорожце - приципив к нему прицеп с бетономешалкой. Тогда нам понадобиться минимальная переделка, нет необходимости в создании инфраструктуры гаража, изменении в бухгалтерии и в целом предприятие получит большую экономию.
Как бы вы оценили профкомпетентность данного человека? :)
Как бы вы оценили профкомпетентность данного человека? :)
,
Я всего лишь хотел сказать, что при таком подходе (как я описал) переход будет менее болезненный.
Однако если клиент уже написан давно и неивесно кем и исходников не осталось, либо в них нереально разобраться, то такой вариант наиболее вероятный и приемлимый.
ЗЫ: работает же 1С по такой схеме... причем клиентов больше сотни выдерживает
Я всего лишь хотел сказать, что при таком подходе (как я описал) переход будет менее болезненный.
Однако если клиент уже написан давно и неивесно кем и исходников не осталось, либо в них нереально разобраться, то такой вариант наиболее вероятный и приемлимый.
ЗЫ: работает же 1С по такой схеме... причем клиентов больше сотни выдерживает
При таком подходе как вы описали - переход не закончиться никогда. Если предприятие не велико - то заканчивалось это безболезнено - покупалась или создавалась нормальная схема работы - и она начисто внедрялась без большой крови. Старая версия использовалась для истории. В хорошо развивающейся компании возможен этот вариант развития если вовремя хватиться. Если же руководство понадеялось на утешения какого нибудь горе-специалиста - то возможны два варианта. Первый - в конце концов "специалист" увольняется (уезжает, или его убивают другие клиенты) - и внедряется нормальная схема.
Второй вариант - на пике работы база благополучно умирает. Срываеться несколько заказов - и дальше все зависит от темперамента директора - я покрайней мере наблюдал случай когда подобного "спеца" просто закрыли в подвале и жрать давали через окошко. :) Работал он так три недели. За жратву. Вполне правильный подход кстати - зарплату до этого он получал? Получал. Свои обязанности выполнял? Нет. Не знаю, работает ли он с тех пор по данному профилю, но суть не в этом.
Я все это к тому - что если это файловая база - лучше обеспечить работу с ней как с файловой базой - и пока все работает, переписать (или написать заново) клиента под нормальный сервер. Тупой перенос таблиц в БД сервера - это наихудший вариант.
З.Ы. Причем здесь 1С вообще не понятно, какое она имеет отношение к теме - и вы в состоянии обсуждать ее внутренние механизмы и реализацию в базе? чтото меня терзают смутные сомнения. :)
У меня у самого возникла подобная ситуация когда я устроился на новое место работы. Бала Аксес база которая потребовала работы с ней несколько сотен клиентов (это было пожелание начальника) и колличеством записей в одной таблице более 50000. Передо мной поставили задачу сделать клиент-серверную БД (мой выбор ессно пал MSSQL). Безболезненный перенос данных длится уже 3 месяц. Клиента я переписал по-новой.
Так к чему это всё я, от старой базы отказываться нельзя только потому, что это работа большого количесва народу и её надо использовать максимально. Плюс изучение этой базы даст возможность избежать ошибок при проектировании новой БД.
Значит всётаки возможно:)
Доступ к таблице будут иметь максиму 2 пользователя, т.к. прога берёт значения из таблице лежащей на сервере(значения поступают с контролера каждые 5 мин) и мне всеголиш необходими брать их и производить дразличные действия.
На первый взгляд мне показалось что проще будит работать с данной таблицей через АДО, но поседев в инете не одни час, я пришёл к решению что наиболее просто будит сделать всё это через БДЕ.!!!
Если же вы считаете что разнице нету, тогда ответтье мне на др вопрос какой выбрать провайдер? ОДБС чтото не хочет
Заранее спс...
Все что необходимо сделать вам - это сформировать следующую строку подключения
:eek: Для меня это не новость и не проблема:
[quote=makbeth]получиться такая вот связка: ADOConnection -> ADO -> Jet OLE DB -> ODBC -> Native BDE Driver :eek: -> *.db[/quote]
Я признал что в одном из более ранних сообщений был не прав по поводу невозможности подключения через ADO. Тем более вы мое сообщение заквотили. А вот вам не стоит разбрасываться громкими словами по поводу чужой и своей компетенции, тем более не зная человека, с которым ведете диалог.
По поводу "нафих оно надо" (c). Сам топикстартер признал, что действительно "нафих не надо" и проще пользоваться теми компонентами, которые заточены под BDE.
Я признал что в одном из более ранних сообщений был не прав по поводу невозможности подключения через ADO. Тем более вы мое сообщение заквотили. А вот вам не стоит разбрасываться громкими словами по поводу чужой и своей компетенции, тем более не зная человека, с которым ведете диалог.
По поводу "нафих оно надо" (c). Сам топикстартер признал, что действительно "нафих не надо" и проще пользоваться теми компонентами, которые заточены под BDE.
Вроде как проблему обсудили и решили. Если вы считаете что ваша "компетенция" чемто задета - пишите в приват - что и конкретно какое сообщение вас задело - я его исправлю дабы оно вас не задевало. На счет топикстартера - ему помоему все равно что использовать - и то и другое требует вдумчивого чтения справки как минимум.