Ivan_Pisarevsky,

боже упаси ему с его опытом работать напрямую с бинарными данными!

Di_LIne,

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

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

....а то он потом ещё одного мертворожденного монстра слепит в итоге.

Симонов Денис,

я сейчас плохую вещь скажу, но:

1) в 2014 году он написал временную и убогую затычку. Все - и он сам и контора - знали что это временная дрянь, которую надо как только представится случай заменить на что-то настоящее

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

3) это значит, что контора должна была либо искать на замену этой затычке нормальный "коробочный" продукт, либо нанять опытных программеров "со стороны" которые бы написали нужное. ЛИБО принять решение, что затычка становится основной программой и озаботиться обучением автора и оценкой кода самой затычки и его масштабируемости.

Ни он ни контора этого не сделали. Два года у них было, но не сделали ничего.

И пришла жопа.

И лучший вариант для них сейчас - "жопа об жопу и кто дальше".

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

Причём контора автора всерьёз не очень-то воспринимает (заслужено или нет - не знаю и судить не буду) судя по "вот тебе два гига на сервер и больше не получишь" (и это в критический момент).

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

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

Я в свое время на похожее натыкался. Без меня про**али и БД и ее резервные копии.
Потом все вместе восстанавливали БД с бумажных распечаток и прочих косвенных документов.
А потом меня же и уволили, потому что "написал такую БД, которая в момент перебоев с электричеством сама себя стёрла" и наняли контору со стороны чтобы всё переписать наново.

тогда уж нe .EOF а .IsEmpty

но как вариант - "а что? а вдруг?" - у него там что-то аналогичное left join и проверять надо именно IsNull

в общем, советы по частностям реализации я бы поостерёгся давать.

dgdogТолько вот вопрос почему на 1024 разницы с 75 не ощутил

а патамушта

Ariochчтобы ПОСЧИТАТЬ значения - нужно преставлять сколько и каких данных твоим программам реально нужно, и как сбалансировать 2гб оперативки между ВСЕМИ подключенными программами

ВСЕ программы (точнее все их подключения) вместе взятые при 1024 выжрали больше памяти, чем у сервера в наличии, и сервер упал в пейджинг со всеми вытекающими

а при 512 - кажется - пока 2ГБ хватало
но если подключений станет больше - всё равно в пейджинг упадёт :-)

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

Di_LIneAriochесли у них контора реально способна внезапно вырастать в сотню раз
- то ему придется переходить к параллельной обработке раньше или позже

Не передергивай.
Монстру он сваял в 2014 (начало кризиса) , а ща какбэ 2016 на дворе. И оборот мог вполне вырасти в разы.

Но-но, парниша! У меня все ходы записаны!!!

dgdogВсе было разработано, все работало как надо, но в один миг СИЛЬНО увеличилась нагрузка ( в сотни раз , фирма развивается и на такие нагрузки, я просто не расчитывал)

Симонов Денис,

если бы начальство читало такие форумы - они бы до такого не довели

а как подсидеть и свалить вину они и так знают лучше нас с тобой и всех форумов в мире

dgdogИ кстати да, можно ли без особых последствий, с моей кашей, уйти хотябы на 2.5?

не попробуешь - не узнаешь

ОБЫЧНО все нормально, но кто ж знает что там у тебя где написано....

поставь параллельно к 2.1 ещё 2.5, перетащи пользователей security2.fdb (надо ли ее обновлять как-то при этом - не знаю), и попробуй из автозапука убрать 2.1 и поставить 2.5 - и молись потом

и не меняй структуру базы под 2.5 - иначе обратно на 2.1 же не вернешься

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

правда эти инструменты нагружают сервер больше, чем работа с самой БД

так чт оесли у теб сервер уже не шевелится, то с включенной трассировкой и просто помрёт

dgdogибо это уже не Delphi 4 и не Interbase 5

раньше на Ibase.ru был для новчиков список литературы

и была там книжка то ли Шувалова то ли Шулимова - название какое-то типа "разработка приложений БД на Delphi для Interbase"

причём если на сайте упомяналась D5, то у меня дома лежит вообще её издание для Delphi 3

так вот, если бы вы ее прочитали - то такого кода, который вы привели, вы бы не родили.

у вас проблема не в версиях Дельфи, а в принципиальных моментах "что когда и зачем делать", а они с момента поядлвения SQL не менялись

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

какие же они обобщённые, если они только про его котору и ни про что кроме?

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