Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2006.06.04;
Скачать: [xml.tar.bz2];

Вниз

MS SQL или MySQL   Найти похожие ветки 

 
beglec ©   (2006-04-08 13:28) [0]

Возникает потребность к переходу на SQL платформу.
В сами программы не нужно переделывать - они уже и так все пользуются SQL запросами. Но через одну мою процедуру. Моя процеДурка использует пока локальные базы Paradox.
Данные растут запросы тоже. Но пока все хорошо работает, причем довольно шустро, база не лопается - хотя уже и 400 тыс. записей - даже индексы не слетают. (Это я к тому, что здесь бывает часто жалуются, что Paradox это есть не хорошо) фигня - главное голова и руки.
Ну так вот - планируются существенные изменения и очень большое увеличение данных. По прикидкам, анализам и предварительным тестам - Paradox справится. Но затраты на создание такой вещи - существенно больше, нежели если этот проект делать на прямую с SQL сервером. Еще вскрылся один недостаток у Paradox это то, что он плохо работает с WWW (php). Мало кто его поддерживает. А интернет дело такое.

Так вот, пока не поздно надо делать выбор, но какой?
Подскажите пожалуйста
1. Ссылку, где доходчиво написано разница между MS SQL и MySQL? (после просмотра популярных статей (через поисковик) в internet на эту тему понял, что пишется везде одно и тоже и одна вата – размытость, ничего конкретного. Видимо друг у друга переписывают. Многое что написано неправда – проверено.
2. Напишите, кто уже писал программы на Delphi под эти сервера –  есть ли какие нибудь подводные камни – что бы их можно было сразу учесть при проектировании.
3. Какие компоненты можно использовать для работы с БД (кроме ADO) и в чем их преимущество?

В данный момент у меня уже стоит и MS SQL и MySQL
Выяснил следующее:
MS SQL - работает хорошо с Delphi, имеет быстрый коннект, это плюс
MySQL не совсем корректно работает с Delphi (нет компонентов), это минус
MySQL много платформенный, это плюс.
MS SQL имеет отличный анализатор и сбор статистики - это большой плюс

P.S. А еще меня вопрос все время мучает. А что конкретно то передает SQL сервер клиенту по сетке. Что именно передает SQL по сетке? Сжимает ли он их для более быстрой передачи? Где и как можно посмотреть трафик SQL сервера? Сколько байт, записей, передано? Было бы не плохо и про это почитать.

P.S.S. InterBase и Informix отпали – потому как умерли при создании в цикле 1 000 000 записей более чем на 4 часа. MSSQL и MySQL справились с этой задачей за 20 минут. Поэтому выбор остановился на них.

P.S.S. Еще есть выбор DB2, но по этому продукту у меня совсем мало русскоязычной информации, хотя и хвалят его очень и очень положительно и по скорости и по мобильности.

Спасибо.
Извините за большую писанину, просто хотел более четко изложить суть своей проблемы.


 
Nikolay M. ©   (2006-04-08 18:33) [1]


> хотел более четко изложить суть


А в результате - много воды о непонятных критериях "лучшести" (какой-то "быстрый коннект", "нет компонент для MySQL" - если ты их не нашел, это не значит, что их нет и тд).
Кстати,  цены MySQL vs MS SQL в расчет принимаются?
Ответы на все вопросы заслуживают отдельной статьи, а меценаты сейчас не в моде. Продолжайна блюдение. Ищи статьи, сравнения и все остальное. Можешь начать отсюда, форумы по обоим серверам присутствуют
http://www.sql.ru/forum/actualforum.aspx


 
Anatoly Podgoretsky ©   (2006-04-08 19:36) [2]

beglec ©   (08.04.06 13:28)  
В сами программы не нужно переделывать - они уже и так все пользуются SQL запросами.

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


 
atruhin ©   (2006-04-09 07:21) [3]


> InterBase и Informix отпали – потому как умерли при создании
> в цикле 1 000 000 записей более чем на 4 часа.

А может вы просто не умеете его готовить?


 
YurikGL ©   (2006-04-09 15:20) [4]


> MySQL не совсем корректно работает с Delphi (нет компонентов),
>  это минус

dbExpress


 
beglec ©   (2006-04-10 10:35) [5]


> Anatoly Podgoretsky

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


> Nikolay M. ©
> А в результате - много воды о непонятных критериях "лучшести"
> (какой-то "быстрый коннект", "нет компонент для MySQL" -
>  если ты их не нашел, это не значит, что их нет и тд).


я написал то что уже успел найти и попытался сократить время поиска - разместив свой вопрос сюда.


> atruhin ©   (09.04.06 07:21) [3]
> А может вы просто не умеете его готовить?


проверял не только я, но и знающие люди которые работали с этим базами.

После ночных поисков пока больше плюсов в сторону MySQL.

P.S. Да! цена - тоже фактор.


 
sniknik ©   (2006-04-10 11:00) [6]

> Изначально все программы проектировались таким образом, чтобы можно было переходить на другую SQL платформу без болезненно и без
> переделки запросов. И это мне удалось!
т.е. переводя на понятный язык, используются только те контрукции, которые поддерживаются всеми sql серверами?
тогда в выигрыше будет самый простой с неразвитой функциональностью сервер. (ну к примеру простая выборка select, на сервере поддерживающем/неподдерживающим тригеры будет (в идеале, не учитывая других факторов) выполнятся быстрее на неподдерживаемом... т.к. на те же проверки есть тригер/нет тоже время нужно). и т.д. любая возможность/особенность,  которая при использавании дает преимущества/скорость, при неиспользовании будет недостатком/тормозом (при сравнении с системой этой особенности не имеющей).

в общем, при твоем подходе, MySQL это лучший выбор. (и ирония одновременно, писать "универсально" для того чтобы потом, и изза этого, выбрать самый убогий движок... ;о)))

> P.S. Да! цена - тоже фактор.
0 vs 0 (если не гнаться за промышленными маштабами)


 
Anatoly Podgoretsky ©   (2006-04-10 11:11) [7]

beglec ©   (10.04.06 10:35) [5]
Только сверх простые запросы можно переносить без переделки


 
Sergey13 ©   (2006-04-10 11:15) [8]

Даже при формальной переносимости запроса, он бывает неработоспособен по сути. Например Select max(id) form table для получения ИД новой записи будет вполне работоспособен везде, однако пользоваться им в многопользовательской среде - мягко говоря неправильно.


 
Плохиш ©   (2006-04-10 11:40) [9]


> MS SQL - работает хорошо с Delphi, имеет быстрый коннект,
>  это плюс
> MySQL не совсем корректно работает с Delphi (нет компонентов),
>  это минус

Хотелось бы услышить, какие это есть специальные компоненты для работы с MSSQL?


 
beglec ©   (2006-04-10 11:45) [10]


> Плохиш

Разобрался со многими вещами уже.
например ADO имеет по умолчанию способо соединения с MSSQL
а что бы это дело заработало с MySQL - то нужно дополнительно скачивать приблуку с сайта ADO. Скачал ужо все робит.

MS SQL - идентификация пользователя проходит довольно быстро - быстрее всех по времени.
Потом идет по времени MySQL
самый долгий InterBase - пока не разобрался почему. Но идентификация пользователя доходит до 5 минут.


 
Sergey13 ©   (2006-04-10 11:48) [11]

2[10] beglec ©   (10.04.06 11:45)
Ты пишешь программу по установлению коннекта? 8-)


 
Плохиш ©   (2006-04-10 12:32) [12]


> beglec ©   (10.04.06 11:45) [10]
> Разобрался со многими вещами уже.
> например ADO имеет по умолчанию способо соединения с MSSQL

Ну да, и клиента ставить не надо?


 
sniknik ©   (2006-04-10 12:42) [13]

> Ну да, и клиента ставить не надо?
в общем случае нет, он входит в MDAC. поставить ADO без клиента MSSQL это надо еще постараться... и еще не факт, что получится.


 
beglec ©   (2006-04-10 14:23) [14]


> Ты пишешь программу по установлению коннекта? 8-)

Да нет :)))
просто клиенты ругаются когда долго коннект идет, не важно где :)

Многие ведь ругаются когда модем долго соединяется или Windows долго грузится :))) вот и долгий коннект с базой тоже выводит из себя народец. Нервный у нас народец нынче :) - поэтому и является  данный факт (факт долгого коннекта) важным фактом при выборе ПО СУБД.


 
Sergey13 ©   (2006-04-10 14:33) [15]

2[14] beglec ©   (10.04.06 14:23)
Например, иногда, некоторые программисты во время коннекта открывают все датасеты (а некоторые могут запрашивать все записи из нехилых таблиц), и потом удивляются, что "коннект долгий". В случае с FB на ХР, если файл базы имеет расширение GDB, то нарываются на (кажется) резервное сохранение файла. Там это расширение зарезервировано. Разные, вобщем, бывают причины "долгого коннекта".


 
atruhin ©   (2006-04-10 15:24) [16]


> самый долгий InterBase - пока не разобрался почему. Но идентификация
> пользователя доходит до 5 минут.

Я же говорю, вы не умеете его готовить.

> [15] Sergey13 ©   (10.04.06 14:33)
> В случае с FB на ХР, если файл базы имеет расширение GDB,
> то нарываются на (кажется)

Именно так хуже то, что при таком варианте в случае сбоя XP база вылетает на дату воостановления :)

> проверял не только я, но и знающие люди которые работали
> с этим базами.

Приведи скрипт таблицы на которой вставка 1000000 записей занимает у тебя больше 4 часов. Посмотрим.


 
Курдль ©   (2006-04-10 15:34) [17]


> После ночных поисков пока больше плюсов в сторону MySQL.


Кстати, а она научилась работать с транзакциями, серверной логикой и т.п.?


 
beglec ©   (2006-04-10 15:53) [18]


> Кстати, а она научилась работать с транзакциями, серверной
> логикой и т.п.?

пишут что с 5.0 научился


> Sergey13 ©   (10.04.06 14:33) [15]

хорошо поразбираюсь - интересное замечание - спасибо


> Я же говорю, вы не умеете его готовить.

может быть, может быть.
я пока на стадии выбора, есть время повыбирать и послушать мнение бывалых.

Как говориться в спорах рождается истина.

в сторону MySQL смотрит также тот факт, что есть 2 программера пишушие на PHP и работаеют с MySQL - но пока пишут всякие мелкие справочники.
Если остаться на MySQL - то переделка их справочников займет мало времени. Но вот в будущем если SQL сервер будет выбран не верный то переделка этих маленьких справочников будет цветочками.
Соглашусь с тем, что каждый SQL сервер где то хорош а где имеет погрехи. Идеальных вещенй не бывает.
Например пока особо "SQL функции" не нужны. Но это может оказаться обманчивым - ведь я пока не знаю всю прелесть данного инструмента.
Есть большая потребность в "Ключах" потому как текущая модель практически вся построена на них. Кто как с ними работает :)))

Вороче на распутье я еще!
Спасибо всем кто помог хоть каким то дельным советом.


 
Sergey13 ©   (2006-04-10 15:58) [19]

>Есть большая потребность в "Ключах"
В смысле?


 
Курдль ©   (2006-04-10 15:59) [20]


> Есть большая потребность в "Ключах" потому как текущая модель
> практически вся построена на них. Кто как с ними работает :)))


Вообще, конечно, топик загадоШный, как и автор.
Что значит "потребность в ключах"? Имеются в виду первичные и внешние ключи? Модель реляционной базы всегда бывает построена на них. А как иначе?
А последнее предложение - это шЮтка, или вопрос?
Если вопрос, то все работают с ними до скучного однообразно, если для проектирования базы используют CASE инструменты. Последние не дадут про них забыть или использовать не по назначению.


 
beglec ©   (2006-04-10 16:25) [21]

Нет вопросов больше нет.
сижу вот только взвешиваю все за и против.
Считаю что прочитал достаточно для предварительного выбора.


 
Курдль ©   (2006-04-10 16:31) [22]


> beglec ©   (10.04.06 15:53) [18]
> Идеальных вещенй не бывает.


Кстати. Идеальных вещей не бывает. Идеальные СУБД - да.
Это oracle. Причем забавно, что Вы прошлись по всему спектру, от Парадокса до DB2, а про оракл - ни слова :)


 
Sergey13 ©   (2006-04-10 16:32) [23]

2[21] beglec ©   (10.04.06 16:25)
>Считаю что прочитал достаточно для предварительного выбора.
Отсюда вывод - ты прочитал недостаточно. 8-)


 
beglec ©   (2006-04-10 17:20) [24]


> Отсюда вывод - ты прочитал недостаточно. 8-)

Ключевое слово "предварительного"
а вот окончательно ... :)

oracle-> может быть и идеальна - но по просьбе трудящихся, руководства и других продвинутых пользователей было отброшено за пределы обсуждения. Не знаю почему. Но четко было сказано - Oracle не предлагать - поэтому обсуждения по нему и не было.


 
sniknik ©   (2006-04-10 17:26) [25]

> Идеальные СУБД - да. Это oracle.
особенно идеально там реализован сетап... (версия 8i) ;о))
с установкой и утилитами реализованными исключительно фанатами оракла и на добровольной основе... контере производящей "идеальную" СУБД, этим заниматься както недосуг...

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

3 раза сталкивался с ораклом, 2 из них впечатление отвратное, 1 так себе, ничего особенного. идеальности не "просек", не повезло наверное... ;)


 
sniknik ©   (2006-04-10 17:29) [26]

> Но четко было сказано - Oracle не предлагать
поддерживаю. если есть выбор между ним и MSSQL то... выбора в общем то и нет. MSSQL гораздо более безпроблемнее, и проще в обслуживании, и вроде дешевле (но тут не скажу точно надо сравнивать последние цены).


 
Джо ©   (2006-04-10 22:26) [27]

А, кстати, вариант с PostgreSQL обсуждался?


 
ANB ©   (2006-04-11 09:15) [28]


> если есть выбор между ним и MSSQL то... выбора в общем то
> и нет.

Конечно нет. Оракл - однозначно.


 
Курдль ©   (2006-04-11 10:14) [29]


> MSSQL гораздо более безпроблемнее, и проще в обслуживании

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

Кстати, MS SQL 2005 уже версионник, а не блокировщик, как его предшественник? (А то я что-то в хвалебных анонсах эту заявку видел, а после релиза что-то не найду...)


 
sniknik ©   (2006-04-11 10:48) [30]

> Мы ставили сервера оракла в такие фирмы...
вот именно что ставили... сами. а с MSSQL без проблем проходит вариант с установкой всего самим юзером, и без дальнейшей поддержки, с трудом представляю что могбы обяснить юзеру удаленно как ему поставить сервер оракла (помня собственный опыт), для MSSQL простого руководства на 3х листах (в основном картинки) обычно хватает, для версий c MSDE и того не надо все общем сетапе ставится.
не знаю, может у оракла что и изменилось, уже же 10версия есть, а сужу по 8й (с чем столкнулся, по тому и сужу...), но смотреть снова не хочется, впечатление уже потерял... ;)

> Кстати, MS SQL 2005 уже версионник, а не блокировщик
а х.з. у нас пока 2000й, 2005й проверяли на возможность перехода (в общем положительно, но кое чего мне там не понравилось по сравнению с 2000м) когда он был еще бетой, год назад примерно но пока не перешли. а потому и не было углубленных выяснений что там к чему.


 
Курдль ©   (2006-04-11 10:57) [31]


> не было углубленных выяснений что там к чему.


Ну так ведь не иголку в сене ищем!!! Такое разительное отличие, как блокировщик/версионник можно было заметить, раз Вы апологет MS SQL Server?! :)
Мое отношение к продуктам MS разительно изменилось с недваних пор. Их последние ОС вовсе не кажутся мне упадочными. А уж MS VS - вообще непревзойденный инструмент! Честно говоря, я жду - не дождусь, когда же у них появится конкурентноспособная СУБД. Но пока, как я понимаю, грустное расставание с ораклом еще не близко.


 
Sergey13 ©   (2006-04-11 11:01) [32]

2[30] sniknik ©   (11.04.06 10:48)
Мне кажется, что легкость установки сервера БД масштаба предприятия юзером, не такое уж и преимущество. Хотя надо признать, что проблемы у 8-ки на П4 при установке действительно были. Но винить в этом Оракл, немного не корректно, ибо писался сервер еще до появления П4.


 
Курдль ©   (2006-04-11 11:14) [33]

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

Мы как-то делали один проект, и в процессе пуско-наладки даже не ездили к заказчикам. Научили пользователей (даже операционисток) снимать/заливать дамп и слать нам по почте - и все. Больше к их ораклу мы не прикасались.


 
Sergey13 ©   (2006-04-11 11:22) [34]

2[33] Курдль ©   (11.04.06 11:14)
>Однако, правильно поставленный оракл дальнейшего вмешательства не требует.
Только если он не работает. 8-)


 
sniknik ©   (2006-04-11 13:02) [35]

> Ну так ведь не иголку в сене ищем!!! Такое разительное отличие, как блокировщик/версионник можно было заметить, раз
> Вы апологет MS SQL Server?! :)
и как это заметить на установке сервера, последовательном запуске некоторых наших программ на предмет работают ли без переделок, проходу по утилитам работы с ним и удалении... ? я даже ни одного сложного запроса в нем не выполнил. если по этому я должен был понять ... ты слишком хорошего о бо мне мнения, я не понял.

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

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

Sergey13 ©   (11.04.06 11:01) [32]
> Мне кажется, что легкость установки сервера БД масштаба предприятия юзером, не такое уж и преимущество. Хотя надо
> признать, что проблемы у 8-ки на П4 при установке действительно были. Но винить в этом Оракл, немного не корректно, ибо
> писался сервер еще до появления П4.
ну про промышленные маштабы никто не говорил. а "претензия" у меня не к проблеме, если не понял, а бардаку в сетапе, проблему то давно решили, иначе патча бы не было. но почему все так и осталось на уровне любительских "заплаток"? там бы где у MSSQL давно был бы кумулятивный (вбирающий все ранние) SPх, там у оракла на диске просто набор папок даже без общего описания, и порядка установки, а ставить все патчи надо в строгой очередности. (в одной из очередных попыток пытался исходную установку "накрыть" последним переписываемым образом, не получилось, многих файлов просто не хватало. поставить после него первый... версия не та. и т.д.)

вообще впечатление от него как от линукса - набор/свалка различных программ... не умееш заставить работать их вместе - сам ламер.
ну так линух то бесплатен, на энтузиазме пишется, а тут коммерческий продукт.

и еще впечатление, что они больше чем разработкой и удобствами пользователя озабочены внедрением в сознание масс мифа "оракл-это круто", по аналогии "C - язык проффесионалов". (обьяснять что язык и профессионализм в основном не связаны думаю не стоит ;)
да видимо досталось им изначально неплохое ядро... но после власть в компании захватили маркетологи и политологи (и мифологи ;)...
ИМХО


 
beglec ©   (2006-04-11 13:41) [36]

эээххх
результат получился тот же самый :)))
столкнулись два лагеря
Аля Oracle и аля MS SQL :)))
кто то хвалит чтото, кто то хаит чтото. Данная картинка наблюдается везде на форумах.

Лично я склонился к MySQL :))) изПисал ажно 3 листа печатного текста сравнительных характеристик - пока документальных :)

сегодня выложу рельные тесты
ради научного эксперемента скачал oracle - установлю - посмотрим

постараюсь сделать сравнение
MySQL
MS SQL
ORACLE

P.S. Проблему с MySQL связывают скорее всего с его устнановкой :)) Действительно, это проблема, особоенно под Windows :) но я разобрался - теперь ставлю MySQL на любую машину гораздо быстрее, чем другие подобые продукты :)))
Хотя есть опредлеленный геморой с файлами *.cfg :) Но в совокупности все такие ставится быстрее.


 
Anatoly Podgoretsky ©   (2006-04-11 14:04) [37]

Ты хочешь нас уговорить? Зря.


 
Sergey13 ©   (2006-04-11 14:07) [38]

2[36] beglec ©   (11.04.06 13:41)
>сегодня выложу рельные тесты
Я боюсь, что после беглого знакомства, у тебя не получатся реальные тесты.


 
beglec ©   (2006-04-11 14:18) [39]


> Ты хочешь нас уговорить? Зря.

нет :) уговариваться никого не собираюсь. Уважаю право выбора каждого!


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

Да сложные тесты провести не удастся - но простенькие тоже многое покажут.

А по большому счету мы все равно до конца, никогда не используем весь функционал любой системы :)

Например Excel - может по настоящему вещи, но многие его использую только для того чтобы посчитать более сложный пример нежели 2+2.

Да я сам не особо его использую, хотя вещь сильная. Также и с Windows - где 90% мы не используем :) также и в SQL серверах. Так зачем мудрить?
Считаю, что лучше посмотреть то, что лучше будет работать с запланироваными вещами, нежели пытаться объять необъятное.


 
Evgeny V ©   (2006-04-11 14:26) [40]

MySql для web не худший выбор. Ставте то, что ваша команда сможет сопровождать и обслуживать, на чем умеете писать. Про IB -

> atruhin ©   (09.04.06 07:21) [3]
>
> > InterBase и Informix отпали – потому как умерли при создании
>
> > в цикле 1 000 000 записей более чем на 4 часа.
>
> А может вы просто не умеете его готовить?

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


 
Sergey13 ©   (2006-04-11 14:42) [41]

2[39] beglec ©   (11.04.06 14:18)
>  но простенькие тоже многое покажут.
Например что?
При выборе сервера наибольшее значение имеют количество одновременных сессий (а так же частота и характер запросов в сессии), количество информации и наличие/сложность серверной бизнес логики. Важна также хорошая структура базы. А "тестовые запросы их многомиллионной таблицы" практически ничего не показывают.


 
Evgeny V ©   (2006-04-11 15:31) [42]

Еще раз про IB "медленный коннект", нашел ссылку на FAQ медленный коннект (и работа) на WinMe/WinXP (и про 2003 там же) http://www.ibase.ru/ibfaq.htm#xp



Страницы: 1 2 вся ветка

Форум: "Базы";
Текущий архив: 2006.06.04;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.61 MB
Время: 0.043 c
2-1147930384
zorik
2006-05-18 09:33
2006.06.04
TPageControl. Скрыть закладки


15-1147092236
ПЛОВ
2006-05-08 16:43
2006.06.04
Во, чего нашел!


3-1144741610
NetBot
2006-04-11 11:46
2006.06.04
Простейший пример IB & Delphi. подключение, запрос, результат.


15-1146887365
Думкин
2006-05-06 07:49
2006.06.04
Суббота


2-1147682133
Hitkliff
2006-05-15 12:35
2006.06.04
Опять WebBrowser





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский