pavlikmd, если ты так и дергаешь базу отдельно на каждую строчку, а не собрал все это в транзакцию - конечно, не помогло.
А если еще и не сделал уникальный индекс по нужным полям - мог и навредить заодно...
Просто stream задает заголовки с типом содержимого и именем файла, а output - нет.
Вам нужно задать заголовок header("Content-type:application/pdf");
чтобы браузер понимал, что это не просто строка, и потом уже вызывать output.
AVTRA, требует чего? Для работы с личными данными тот Дебиан все равно не сертифицирован.
А для практических целей Убунта с шифрованием домашнего раздела (из коробки) - более, чем достаточна.
Это не совсем так. Если шифрованию подвергается каждый отдельный файл - да, разницы нет.
Если зашифрован раздел - например, контейнер TrueCrypt - то каждая запись затрагивает не последовательные блоки, а случайные. А SSD пишут и перезаписывают именно группами блоков. Нагрузка может повыситься в разы.
Константин, насколько я представляю себе Электрон, это и есть - движок Хрома, позволяющий обвесить себя добром, написанным в Javascript (в т.ч. во всяких там реактах) без необходимости лезть в "кресты" и перекомпиляцию. С ним при некотором желании должны справиться ваши же прогеры.
Пересобирать Хром имеет смысл только в том случае, если вы хотите в нем что-то изменить и готовы это изменение поддерживать и далее. У вас такой задачи нет.
Константин, вы же все равно не сможете поддерживать свою ветку, пересобирая браузер после каждого обновления Хрома и предлагая клиентам обновления.
Может, рассмотреть вариант переноса проекта на Electron? Для React-а это вполне естественная среда.
Поскольку вы не специалист и у вас нет команды, готовой разрабатывать и поддерживать - скорее всего, вам не нужен свой браузер на основе Хромиума. Достаточно использовать WebKit, например, с которым крестовик, знакомый с Qt, вполне может справиться.
Просто обобщите задачу и не навязывайте столь амбициозное решение, если не уверены в его необходимости.
Мечта. Если работа не завязана на Windows-only программы - поставить Линукс, перетерпеть месяц криков о том, что ничего не работает, потому что ярлык не того цвета, и забыть про этот офис, потому что там просто все работает, и сломать теткам ничего не удается.
Реальность. Просто отбери у теток права администратора и запрети запуск чего бы то ни было с флешек.
Сергей Горностаев, вот вы смеетесь, а смогли бы назвать другую CMS магазина, у которой запись о заказе в БД - это 75 столбцов только в основной таблице, не считая вспомогательных?
Я лично аналогов не знаю... к счастью...
Camaro67, при проектировании оплаты задумываться над вариантами развития событий и гарантией того, чтобы пользователь получил то, за что заплатил - это хороший шаблон.
А вот делать только то, что встретилось в документации, а потом разгребать реальные юзкейсы - не очень.
Camaro67, кто из нас не видит этой разницы?
Половина способов оплаты на Робокассе происходят НЕ на сайте Робокассы. Какой бы SuccessURL вы ни выставили - клиент по нему тупо не попадет, поскольку с сайта Робокассы он уже ушел, и возвращаться ему туда незачем.
В той же документации, собственно, и написано, что совершать какие бы то ни было действия нужно в обработчике ResultURL, а SuccessURL - это так, для декора.
Camaro67, не ткнете меня, скудоумного, в то место документации, где рассказывается, как клиент вообще попадет на сайт Робокассы после успешной оплаты, скажем, через Евросеть? А то я последний раз читал документацию, когда подключал Робокассу, это было лет восемь назад...
Второй цикл стоит исправить так, чтобы в нем использовалась переменная цикла.
А в первом стоит задуматься - то ли i = 0, то ли i <= countstring. Вряд ли то и другое одновременно.
А если еще и не сделал уникальный индекс по нужным полям - мог и навредить заодно...