ADO и SQL

На счет технологий ADO and SQL<br>Организация большая, зарплата - тоже, причем на 1с 77(понимаете - тормозит)<br>Решил некторые узкие места переписать с использованием технологий ADO и хранимых процедур SQL.<br>Добьюсь я результата или нет?<br>И вообще стоит мне, рядовому программеру, лезть в эти дебри?<br>

<br>> И вообще стоит мне, рядовому программеру, лезть в эти дебри?<br><br>Насчет ЛИЧНО Вас - неизвестно. Может быть, Вы круче и 1с, и Майкрософта с Биллом...<br><br>Вот только ЧТО будет делать эта компания ПОСЛЕ Вашего ухода? Или Вы еще и "вечный сотрудник"?<br><br>

С Вашими знаниями типовых конфигураций, не стоит! Без обид, но если Вы задаете вопрос по поводу вычетов, то лучше пусть как будет! ИМХО

Согласен типовые конфигурации я еще и не очень хорошаю знаю и никаких учебных центров 1с я не заканчивал,и занимаюсь я им где-то только год, но разогнать 1с как-то надо. <br>Может тогда существуют другие средства? Про конфигурацию сети,терминальный сервер и SQL-базу уже известно.<br>А выше изложенные я прочел с дисков ИТС и сайтов посвященных 1с.(люди же пишут значит переписывают...)<br><br><br>

Тогда придется ответить конкретнее:<br><br>> Добьюсь я результата или нет?<br><br>Нет, но по иным причинам, чем Вы предполагаете.<br>

> Добьюсь я результата или нет?<br>это вообще-то дело времени, что ЛИЧНО касается меня.<br>Но "вечным сотрудником" не хочется быть. Здесь при уволнении можно просто подписать договор на поддержание данной конфигурации. И длится это будет не вечно, а думаю годиков так 2-5 примерно. И за этот период буду иметь некоторый зароботок, чего и добиваюсь. А там они уже передут по-любому на восьморку какую-нибудь скажем 8.8.<br>Хотя начальство и щас думало переходит на специализированную конфу, написанную на 8.1, но внедрение его в общей сумме выходит больше лимона - отказались.<br>А если немного пофилософствовать. А зачем вообще тогда эти ADO и SQL, причем разработано их внутренняя поддержка 1с77, для крутости или для переписывания "узких мест"? Думаю скорее всего для переписывания "узких мест", но крутости тоже добавляет. И я думаю неправильно их не использовать, когда 1с становиться просто "системой тормаз" в связи с его большим объемом информационной базы. Ну я знаю там есть обработки такие например как wrap.ert, который урезает бухгалтерию и позволяет как-то его ускорить. Но его целесообразно же использовать только вначале года. А если в день вводится по 500 доков, то куда деваться, если у предприятия только 1с 77, а через полгода бухи начинают на тебя жаловаться "что выполняется так медленно, ждем уже полчаса, сделай уже что-нибудь". И концу года есть только одно желание - уволиться, а тебя все равно не уволят так просто, потому что бухи понимают что новичок с задачами, которые стоят в конце и начале года, врятли справиться. Так что здесь не только крутость, а повседневные задачи программиста, которые он должен решать и за которые он получает бабки. А вообще у нас в России такая ситуация, что полноценного программера из тебя нигде не сделают. Вот когда я учился эти ADO даже толком не упоминали. Поэтому все равно что-то на стороне придется подучывать, а SQL в особенности, потому что на сегоднешний день он является самой распостраненной системой для управления БД.<br><br><br><br><br> И если я помру все равно другой найдется, свято место пусто не бывает.

<br>> И если я помру все равно другой найдется, свято место пусто не бывает. <br><br>Тьфу-тьфу, что называается.<br><br>Но, увы, и такое лично мне приходилость проходить. И тоже увы, не раз даже...<br>И всегда путь-то один: убирать "навороты" предшественника, максимально приводить конфигурации обратно к типовым. И уж потом все очень долго работало прилично. И чем дальше - тем все ближе к типовой, до мелочей уже, есть даже полный возврат к типовым от жутко навороченных, и именно доставшихся в такой вот печальной ситуации.<br><br>Так что я - против "художеств". А уж Вам и заказчику решать...<br><br>PS. А на самом деле не от платформы, и даже не от конфигурации надо плясать, а от учета. Зачастую, там "собака порылась". Только это - разобраться в деталях с учетом - долго и нудно. Проще быстро чего нибудь "запулить" экзотического. Например, ЗиК, в которой всего два пользователя работают, в SQL формат перевести. Это же круто!

"Типовая" ЗиКа на SQL для расчета хотя бы 5000 сотрудников - это трындец. А вот переписанная на прямые запросы - вполне даже ничего себе работает. Новые сотрудники, которые устраиваются за 3 дня в ней разбираются. Так что "типовые" это когда нужно 5 человек расчитать.