barry fominТехнически ничто, но придется переделывать очень большое кол-во отчетов в Crystal-е, отчетов в VB+Excel, Excel+quote, писавшихся не один год.
??? Интересно кому же пришла в голову такая гениальная мысль - так отчеты делать... Тем более не один год. :-)А почему нет?

barryНу если я правильно понял - в отчеты зашили имя сервера? Что же в этом нормального?А что в этом ненормального?
Использовать имя сервера намного удобнее. Не нужно на всех клиентских машинах создавать DSN. Просто инсталлируешь им ODBC драйвер доступа к ASA, и все. Отчеты смогут вытягиваться с любого из серверов в локалке. У меня например в локалке сейчас около десяти разных серверов. Каждый от одной до четырех баз держит. Предлагаешь на каждом новом компе в офисе заводит по два десятка DSN? А так, понадобился главбуху отчет по данным из какой-либо баз - делаешь отчет с DSN-less подключением и отдаешь главбуху. А он может этот отчет (в виде Кристала или Экселя) отдать любому из бухгалтеров, на любой из их компов. Везде будет работать :)

Вот ставить два одноименных сервера в одной локальке это действительно ненормально. Но если нужно, то можно :)

iLLerЗашивать имя сервера в клиента, также ненормально как и зашивать в клиента имя профиля DSN. В клиента вообще не надо ничего зашивать, касающееся
подключения к БД, а информацию такого рода нужно выносить из кода в
настройки.Это не всегда возможно. Далеко не все "клиенты" теоретически позволяют выносить что-либо наружу. А в этом случае наиболее правильным будет зашивать в клиента именно DSN.
Вообще, в этом случае надо смотреть на конкретную ситуацию, что за клиент, откуда он будет к серверу ходить и многое-многое другое.

iLLerА если развить эту мысль, то при подключении можно использовать целиком строку подключения, хранящуюся, к примеру, во внешнем файле. Тогда механизм подключение клиента к БД будет совсем изолирован от драйвера ODBC, и в течении жизни клиента будет возможным сменить не только имя сервера/базы/машины, но и даже версию драйвера
А это и есть DSN в чистом виде :)

iLLerили вообще СУБД.А вот это уже нереально. Клиент в любом случае пишется под конкретный диалект SQL и смена сервера всегда тянет за собой переписывание всех селектов и/или вызова хранимых процедур.
Чтоб можно было прозрачно для клиента менять СУБД придумана трехзвенка. А это, извините, уже другой принцип а не просто конфигурационный файл.