Almost certainly this is a timeout or a memory issue. The only PHPExcel limit for worksheets size is 65,536 rows and 256 (IV) columns (when using the Excel5 Writer); or 1,048,576 rows and 16,384 (XFD) columns (when using the Excel2007 Writer).
If you right click on a blank spot on your report, you will get a popup menu. Select Database -> Verify__Database. Crystal Reports should update the fields that have changed.
You can drag-n-drop the new field onto your report.
There should be a "Field Explorer" tree view (probably on the left). Select Database Fields -> View/Table Name -> Field Name and drag that onto your report.
В таком случае лучшим вариантом для вас было бы (при отсутствия возможности реплицировать данные с объектов) собирать их напрямую SQL-запросом с коллекора, тем самым вы хотя бы на стороне коллектора сможете с известной степенью удобства отличать данные одного объекта от данных другого. В центральной базе (на коллекторе) вы можете ввести одно поле (object_id). Это если рассматривать размещение данных в одной таблице коллектора.
Есть и другой вариант - собирать данные удаленных объектов в разные таблицы коллектора.
@mynewvk Я не хотел вас обидеть, извините. Фильтрация запросов на уровне приложения, особенно когда это касается РНР - далеко не самый лучший вариант "защиты" приложения. Советы вам дали: fail2ban/iptables или штатные средства nginx/apache помогут справиться с вашей проблемой в известной степени.
@denisov MySQL и репликация это еще несколько кг головной боли ;) Лучшим вариантом будет вынесение мастера на отдельный сервер, а слейвы сделать в тех ДЦ, где будут серера приложений. Но приложения должны использовать, конечно, мастер, и только в случае его аварии переключаться на свой слейв. И тут уже сетевые издержки весьма имеют значение!
В зависимости от требований заказчика, и в большинстве случаев да, используем HAProxy. Про сервера не секрет, но тут тоже зависит сильно от заказчика: Selectel, Amazon, Linode, Hetzner, Digitalocean.
Впрочем, если у вас сайт исключительно информационный и не использует персонализацию, то и сессии вам вовсе не нужны, а значит и нет необходимости в их распределенном управлении.
1) Да, баллансировщик это еще один сервер
2) Если накрывается баллансировщик, то накрывается всё. Альтернативой вы можете использовать ЕЩЕ один сервер для мониторинга баллансировщика и, в случае, если он накрылся, то делать соотв. изменения в записях на NS-серверах. То есть вначале у вас в NS прописывается адрес баллансировщика, в случае его аварии ваша схема должна УМЕТЬ АВТОМАТОМ менять NS-записи.
3) В случае с баллансировщиком А-запись нужно делать на него. Проверку работоспособности серверов приложений/бд будет делать баллансировщик.
4) Сессию лучше не обнулять ;) При обнулении у вас все посетители разбегутся с сайта нафиг. Бороться можно установкой распределенного (и/или реплицируемого) хранилища сессий. Например им может быть Redis.
Ну и если совсем придираться к схеме, то сервера в разных ДЦ разных поставщиков тоже не самая лучшая затея. Если есть возможность, то лучше брать сервера одного поставщика, так можно минимизировать накладные расходы по трафику.
Вот тут человек набирает себе учеников, обратитесь к нему Где найти ученика для PHP А по существу вопроса ответ такой: фильтрация данных делает ваше приложение более устойчивым ко разного рода методам взлома.
Фактическое положение дел таково: stackoverflow.com/questions/4895230/why-phpexcel-d...
Almost certainly this is a timeout or a memory issue. The only PHPExcel limit for worksheets size is 65,536 rows and 256 (IV) columns (when using the Excel5 Writer); or 1,048,576 rows and 16,384 (XFD) columns (when using the Excel2007 Writer).