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

Конкретизируйте, какая задача, что делает приложение, насколько часто происходит доступ к базе.

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

ИМХО, Delphi (или C++ Builder) + Interbase - самое оно для таких задач.
А еще лучше не изобретать велосипед, а достать 1С Предприятие - "Торговля и склад ". Там практически готовое решение со всеми отчетами, формами и т.п.

а почему не visual c++?
просто там хоть какой-то опыт, а билдера я особо не пользовал

Можно и VC++, но там больше тупой работы.
Еще раз повторю: бери 1С, там всё уже готовое

хорошо, погляжу
спасибо

Ежели надо будет в 1С какие-то дополнительные отчетные формы делать, пиши в приват или на мыло craxx@mail.ru, договоримся.

Какие там 1С, VC++, Delphi ?????? Для таких простых задач есть Access!

не, парень, акцест тут просто курит. просто чисто из имплементации столь многочисленных функциональностей..

не, парень, акцест тут просто курит. просто чисто из имплементации столь многочисленных функциональностей..

Это ты называешь функциональностью ? Для таких
вещей задействовать плюсы ???? Это надо же такое придумать... Даже когда я был неопытным студентом, и то бы плюсы не приплел, а нашел какой-нибудь более подходящий инструмент.

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

На Access такое быстро наваять, чтоб и удобно было и интерфейс красивый, не должно представлять никаких проблем.

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

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

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

Аксесс хорош, если используется на одном компьютере, когда хотя-бы две машины в сети используют базу, возникают проблемы.
В Access давно уже есть такая штука как ADP-проект (Access+MSSQL/MSDE). Да и при обычном файл-сервере проблем особых не было...

Да, компьютер действительно один и то изредка требуется

Всем спасибо за комментарии, буду взвешивать ваши советы.

В плане выбора среды остановимся, например, на с++ билдере. Какой в этом случае интерфейс бд выбрать?
В чем преимущества и недостатки InterBase и ADO?
Даже не применительно к данному проекту, а вообще. Кто что может сказать из опыта?
И какой из них все же "лучше" использовать?

Эх, ребята. Если бы видели Common SQL и хоть пару недель по вечерам поразбирались с Common Lisp и средой LispWorks, то не задавали бы таких вопросов вообще. IMHO после этого вообще неуместно поднимать вопрос о Pascal(Delphi) или C++ в области БД. Даже для новичка все было бы настолько просто, как на QBASICе точку на экран вывести.

В чем недостатки Builderов ? Да при нетребовательности задачи по времени, использовать такие низкоуровневые вещи, как Pascal(Delphi) или С++ Builder, становится совсем неуместно. И какой смысл корячится, когда все то же можно сделать почти на порядок быстрее (при условии, что это не Hello World) ?

Прошу не обижаться тех, кому задачи работы с БД кажутся на Delphi или Builderе легкими, как QBASIC ;-)) При отсутствии real-time требований и особенно напряженной работы с битами/байтами Common Lisp не оставил бы этим языкам абсолютно никаких шансов. Собственно, я уже видел, как на Delphi + Interbase была создана система, которую создать на Common Lisp + Interbase было бы в 5 раз проще.

Тут нет никакого элитизма или задирания носа. Просто каждому языку свое:

"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."
- Phil Greenspun

В реальности, я видел как сложная программа на Delphi стала напоминать простую программу на Common Lisp, потому что Лисп отлично приспособлен для метапрограммирования и создания встроенных языков, а на Delphi пришлось создать целую динамическую систему работы с БД, которая кстати иногда неслабо глючила.

А вообще бесспорно, что с Делфи или плюсами работу в Нске найти в XXXXX раз легче, чем с Common Lisp.

ADO очень не советую. Весьма глючная фигня.
Interbase весьма неплох для небольшого числа пользователей, ~10, прост и надежен. Если пользователей >20 тогда лучше MS SQL Server или Oracle.

Странно, а я видел как около 50 одновременно работали и ничего (прога вроде 1С, писана на Delphi). Правда секрет был в том, что уметь надо свои модули писать, чтобы запросы организовать большими пакетами. Interbase - довольно надежная штука.

Я ни в коей мере не утверждаю, что Interbase при 50 пользователях одновременно работать не будет. Я просто хочу сказать, что при числе пользователей >20 MS SQL Server и особенно Oracle покажут лучшие результаты в плане производительности.