Вот на вашем форуме часто решение проблемы зависит от SQL а что делать если у меня его нету - во первых, достать негде , а во-вторых я не умею им пользоваться?
если скачивать то долго?

Ну зависит от того, какая у вас скорость ))
Если нет SQL, и негде его достать (что кстати, удивительно, неужели вы программист полярной экспедиции?)
Вобщем можно использовать другие базы данных. Например, Access, Paradox.

Вообще-то ты на форуме "Delphi: Базы данных и репортинг"
Значит рискну предположить, что Делфя у тебя стоит
А если стоит, то что она у тебя какая-то урезанная чтоли - ну типа без BDE или ADO?

Модераторам: Может у вот этих строчек

пляшущую девушку поставить чтоб народ внимание обращал.

я так понимаю речь идет о SQL - запросах к БД, просто человеку разяснить нужно что SQL это язык манипулирования данными, т.е. спомошью него ты можешь обратится к набору данных какой либо БД.
если я провельно я тебя понял, то доставать его не нужно, а достаточно поставить Delphi, и смошью компонентов TQuery обратится к твоей БД. Ну конечно подчитать нужно умную книжку по SQL ...
если будут трудности и поиском литературы то кинь мыло, я вышлю.

[email protected]
значит добавив ТКВЕРИ можно писать код SQL просто программист я начинающий, живу в небольшом поселке книжных и компьютерных магазинов нету, возможности сгонять куда-нить или попросить по пути купить у кого-нить тоже нету (а вы сразу глумиться) хорошо што нормальные люди есть...
Добавлено @ 22:58
все ведь пищут примерно так
код SQL:
select ....
и так далее
это ведь не в БДЕ пишеться я так понимаю...
и не в АДО...

Если ты мой ответ принял как глумление, ИЗВИНИ ПОЖАЛУЙСТА!!!
Просто я же не знаю твой уровень.
В BDE в компоненте TQuery, в ADO можно в нескольких компонентах писать, зависит от вида запроса. Ты если что - спрашивай. Чем можем, как говориться, поможем.

Отправил.


BDE и ADO это сервиса которые содержат множество драйверов для работы с различными БД.
соответственно в делфи так названы закладки на политре компонентов. Чем пользоваться решишь сам, но скажу сразу - т.к. ты только начинаешь осваивать БД то легче всего начать с СУБД Paradox, который инсталируется вместе с делфей (удобнее использовать BDE) или Access (ADO).
через какие компоненты и как организовать соединение с БД ты найдешь на форуме, эти темы обсуждались неоднократно. удачи!

Foley

Ну можно еще поглумиться .
1 способ:
Если, как начинающий, набрать SQL и нажать волшебную кнопку (F1),
то вывалится куча топиков. Если по ним побродить, то обнаружится, что в дистрибутиве Delphi есть SQL-сервер под кодовой кличкой InterBase. А если дистрибутив не урезан напрочь, то еще и доки по этому серверу обнаружатся. Там про SQL много - читать не перечитать .
2 способ: (если с английским проблемы)
на этом форуме ищем раздел литературы, при некотором желании можно найти в Инете то, что там рекомендуют по SQL в электронном виде. И не надо ничего просить покупать: я за последние 3 года только 1 книжку купил. И то чтобы в новом книжном "отметиться".
3 способ: (если со всем проблемы )
читаем FAQs. Не только этого раздела. Потом все равно читаем книжки. Начать с Дейта. или Кириллова&Громова и т.п. по ПРИНЦИПАМ построения БД. Иначе потом будет мучительно больно за впустую убитые дни.

Спасибо всем что помогла разобраться!!! Просто все от недостатка опыта... Севодня вы мне завтра (дай бог ) я вам помогу...
Кстати не кто не могет сказать мне ссылки на лучшие учебники по SQL (где все понятно и ламеру будет)...
А про то что SQL отдельно идет я подумал после того как увидел чела работающего в SQL мелкомягких...
Добавлено @ 23:28
Ну или хотя бы новичку...(про лит-ру по SQL)

http://www.natahaus.ru/2005/12/23/e_mamaev...S_SQL_2000.html
Да и просто там покопайся.. много интересного..
А вообще еще у нас есть раздел про компьютерную литературу:
http://forum.vingrad.ru/index.php?showforum=150

Foley,
Держи, читай:

Базы всякие нужны, базы всякие важны…

Давно назад, когда компьютеры, даже самые маленькие, по размерам превосходили документацию на их софт, после решения задачи как что-то на них посчитать начали решать задачу как что-то в них хранить и искать. И решали с разной степени успешностью. С той поры были наработаны как практические, так и теоретические методики. Если коротко: от просто таблиц перешли к инвертированным спискам, древовидным и сетевым базам, от них – к реляционным и постреляционным. А сейчас уже вовсю идет соревнование в объектно-ориентированных технологиях, т.е. когда предмет разработки - не только данные, но и процессы их обработки несколькими взаимосвязанными объектами (например пассажир-кассир-пилот-авиадиспетчер…). И все это держится в первую очередь на такой простой, если разобраться, вещи как нормальные формы(НФ). Которые есть всего-навсего набор правил, что нужно сделать, чтобы необходимые данные хранились наиболее эффективно и изменение их качественного состава было как можно проще. Не зная, что такое НФ, можно, конечно, что-то сделать. И это что-то даже будет работать, совсем даже не исключено. Только вот чем дальше, тем больше времени и сил будет уходить на внесение любых, даже чисто косметических изменений этого «что-то». И в конце концов это «что-то», испортив кучу нервов окружающим, будет выкинуто. Вывод: если человек не знает, что такое эти НФ, то проектировать базы данных(БД) он просто не имеет права. И никакие крики о том, что «иначе уволят», «нужно срочно» и т.п. оправданием не будут. Поскольку все равно уволят, а быстрее все равно не получится. В особо печальных случаях уволят не автора, а его преемника - если автор успеет сменить место работы на более оплачиваемое. Ну ладно, не будем о грустном. Лучше почитаем Дейта «Введение в системы баз данных», или Райордан «Основы реляционных баз данных», или еще кого-нибудь. Главное чтобы на обложке или внутри было что-то похожее. Дейт вообще-то полезнее, поскольку уже давно записан в классики. Но кто-то любит коньяк, а кто-то «горилку з перцем».

Я назвал его сервер…

Ура! Свершилось! С помощью лома и чьей-то матери (а кто похитрей – с помощью ErWin или BpWin) структура базы данных разработана. И даже написана программа, которая что-то из нее показывает. И даже редактировать записи можно! Но начальство уже не хочет просто персональных баз данных. Им подавай общую на всех, и чтобы каждый видел только то, что ему положено.
И тут пришло время наступить на другие грабли: положить БД в виде толпы dbf-ок, или одного mdb/gdb-файла куда-нибудь, где всем видно. А потом приляпать везде хитрое поле, чтобы каждую запись можно было редактировать кому-то одному. А можем и не приляпывать – само все образуется. Будем средствами программы блокировать от всех прочих запись, пока кто-то один в нее пишет. FoxPro это умеет. И опять-таки, если так поступить, то сразу проблем может и не возникнет. Проблемы будут потом, причем гораздо раньше, чем в случае с НФ, и гораздо тяжелее. Сменить место работы на более оплачиваемое можно не успеть J. База данных будет периодически терять записи, искажать их, а может и вообще полностью рухнуть с соответствующим приказом по предприятию. Хотя вовсе не обязательно, что это произойдет в первую же неделю эксплуатации. Процесс носит чисто вероятностный характер.
В этом случае правильное решение задачи только одно: сервер. Но не тот сервер, у которого диск всем по сети виден, а сервер баз данных. Например, что-либо из Oracle, MS SQL, InterBase, MySQL, Advantage DS, DB/2 … Эта технология называется «клиент-сервер». Что конкретно из серверов выбрать – зависит от задачи и личных пристрастий. В наше время всяких серверов развелось почти столько же, сколько языков программирования. А может и больше. Не знаю, не считал. Навскидку цифры близкие. Главное не впасть в крайность. Простейший пример такой крайности: установить Oracle и на нем вести базу данных заводской художественной библиотеки – кто какую книгу взял. Это будет как на 10-тонной фуре везти 5 кило песку. Если конечно у вас не 1.000.000 работников и не 1.000.000 книг J. Такой завод тоже крайность. И даже для такого завода Oracle применять не обязательно. Но уже можно.

Сервер, сервер, ты могуч, ты гоняешь стаи юзеров…

Уфф! Оказывается и начальники могут иногда что-то понять! Купили-таки XP ProLiant, хоть что-то, а к нему в придачу APC 1400. Сейчас поставим на него Win2000 server, MS SQL 2000 взгромоздим и порулим дальше. И вот тут уже наступает очередь для 3-их граблей. Условно их можно назвать так: «на сервере по-dbf-ному». Тут для начала имеет смысл прочитать
Переходим на клиент-сервер (советы) Переходим на клиент-сервер (советы). Я правда не разделяю восторгов автора по поводу ADO и неприязни к ODBC. Хотя бы по той причине, что ODBC – открытый стандарт, драйверы писали и пишут все кому не лень, и скорость работы зависит от криворукости драйверописателя и его хитрости. Поэтому очевидно, что, например ODBC драйверы от Micro$oft быстрее всего будут работать с Micro$oft же поделиями, а с прочими – «для галочки». И если при этом мне скажут, что ADO работает с SQL-сервером быстрее, чем ODBC, то я всего лишь процитирую:
«ADO applications access data through OLE DB providers. Microsoft SQL Server™ version 7.0 introduces a native Microsoft OLE DB Provider for SQL Server that can be used by ADO applications to access the data in SQL Server. In earlier versions of SQL Server, ADO applications had to use the OLE DB Provider for ODBC layered over the Microsoft SQL Server ODBC driver. While ADO applications can still use the OLE DB Provider for ODBC with the SQL Server ODBC driver, it is more efficient to only use the OLE DB Provider for SQL Server.» (Microsoft MS SQL 7.0 BOL)
Вольный перевод с небольшими сокращениями: «специально для своих самых крутых MS SQL-серверов самой крутой фирмой Микрософт сделаны самые крутые OLE DB провайдеры, работающие с самой крутой технологией ADO. Если для вашего сервера (например MS SQL 6.5 J) крутого OLE DB провайдера нет – работайте через связку ADO-OLE DB-ODBC.»
Вопрос о том, быстрее ADO или нет, чем ODBC, отпадает автоматически. Или откажитесь от ADO. Т.е. для MS SQL-сервера версии выше 6.5 связка ADO-OLE DB работает быстрее, чем связка ADO-OLE DB-ODBC. Но это не скорость ODBC. На самом деле ODBC дает больше возможностей, но для меньшего количества источников данных. А сам по себе ODBC-драйвер может (и должен) работать быстрее, чем ADO-OLE DB за счет меньшего количества «промежуточных ступеней». Особенно с не-Micro$oft серверами и не-Micro$oft драйвер. Короче, все зависит от того, какой сервер выбран. Если M$ - работайте через ADO. Если не M$ - то и не-ADO. Хотя это и экономия «на спичках». В сбалансированном приложении главными тормозящими факторами будут скорость передачи данных по сети и скорость чтения данных с поверхности диска (дисков) сервера. Но вернемся к нашим баранам: «на сервере по-dbf-ному».
Итак, есть SQL-сервер. Надо для отчета в какой-то таблице (например Payment) узнать сумму по столбцу, ну назовем его MySales. Подход «по-dbf-ному»: переходим в начало таблицы, а дальше в какую-то переменную добавляем содержимое столбца MySales, сдвигаемся на запись вниз и опять добавляем … и так до конца таблицы. Это будет медленно и не всегда возможно.
Правильный подход: заставляем сервер с помощью SQL вычислить нужную сумму и передать ее нам. Что-нибудь вида

SELECT SUM(MySales) FROM Payment

(как передать результат в приложение – зависит от сервера и приложения, но сумма вычислена).
И вот тут мы и получим как говорят в Одессе «две большие разницы». В первом случае нужно через сеть перетащить по очереди, по каждой записи, всю таблицу на машину-клиент и там просуммировать. В этом и заключены медленность и не всегда возможность. Во втором случае серверу на том пресловутом языке SQL, исходников программ на котором почти не дают, скомандовано: «посчитать сумму столбца MySales таблицы Payment» (и передать результат нам – но как это скомандовать уже зависит от того, какой сервер и на чем написано приложение). Главные тут 2 пункта:
1. Вся таблица по сети не передается, передаются команда и результат ее выполнения.
2. Считает результат не клиентская машина, которая может быть сколь угодно слабой, а сервер, который по традиции имеет более мощное и надежное «железо».
Если добавить, что SQL позволяет много другого (не только получение сумм), то вывод прост: работать по технологии клиент-сервер и не знать хотя бы основ SQL – недопустимо. А лучше знать именно тот диалект SQL, который реализует сервер. Иначе при супер-пупер сервере и супер-пупер локальной сети гарантируется скорость работы на уровне ENIAC (компьютер 1946 г. выпуска) – все будет уходить на перекачивание мегабайт данных между сервером и клиентами. А потому для начала, в качестве легкого, почти как дамский роман, но менее объемного чтива берем Грубера(Грабера), т.е. GRUBERа «Понимание SQL». Или Кириллова и Громова – у них и про построение БД и про SQL есть. Кто хочет MS SQL – читает Райордан по 2-му разу. Востриков и Козявин - «Мир Интербейз». И т.п. Найти в электронном виде на русском языке книжку про интересующий сервер – не проблема. Надо лишь знать где искать.

Установлен MS SQL Server 2000, при использовании ADO -> ADOConnection не могу подключиться к серваку (в списке выбираю Microsoft OLE DB Provider for SQL Server, а список серверов пустой)? Что не так?

Спасибо.

Alekse,
"Ошибка в 17 строке". Подробнее можешь?
Сервер на той же машине или другой?
Он точно есть (а не просто его клиент)?

1. Сервер на той же машине.
2. Установлен сервер+клиент MS SQL Server 2000DE

Это сообщение отредактировал(а) Alekse - 9.3.2006, 17:55

Присоединённый файл ( Кол-во скачиваний: 11 )
 Service_Manager.jpg.jpg 23,15 Kb

Alekse,
У меня по-другому. Сервер всегда получает имя машины, на которой стоит. Без подкаталогов. Если ее переименовал - вертай взад.
Т.е. у меня тачка serge- и сервер с именем \\serge-