ничего не пониманию из вашего диалога...PeterK писал(а): ↑14 июл 2024, 10:27 Что значит «не совместимо» ? Все совместимо.
https://enterprise.arcgis.com/en/server ... gresql.htm
Проблемы возникнут только если пытаться перенести on-premises базу на RDS через backup/restore. В RDS варианте нужно использовать другие stored procedures. Вместо backup/restore нужно создать новую базу на RDS и перенести данные нашим софтом.
Но, похоже, PeterK побеждает СтаниславаК по очкам. 
Поставщик всегда побеждает клиента.pin писал(а): ↑15 июл 2024, 09:12ничего не пониманию из вашего диалога...PeterK писал(а): ↑14 июл 2024, 10:27 Что значит «не совместимо» ? Все совместимо.
https://enterprise.arcgis.com/en/server ... gresql.htm
Проблемы возникнут только если пытаться перенести on-premises базу на RDS через backup/restore. В RDS варианте нужно использовать другие stored procedures. Вместо backup/restore нужно создать новую базу на RDS и перенести данные нашим софтом.
Особенно когда клиент не читает документацию и пытается делать все по своему. Это не только к LTSA относится.Поставщик всегда побеждает клиента
А мы все оплатили - у нас 10 чел из ESRI работает - мы просто следуем их советам.
Советовал?
Ну вотPeterK писал(а): ↑19 июл 2024, 10:54 Ха, они были правы. Parcel Fabric до сих пор не работают на RDS. Из облачных систем только Azure SQL их поддерживает.
Похоже, так и не смогли найти решение проблемы RDS - там юзеры (которые не DBO) не могут получить доступ к некоторым функциям базы которые нужны нашему софту.
https://pro.arcgis.com/en/pro-app/lates ... 5D1246F3E4
Я чиста, чтобы показать, что вы сами себе не можете правильно поставить вопрос.
Бывают такие проекты, у которых время их выполнения тупым кодером проближается к бесконечности...Stanislav писал(а): ↑20 июл 2024, 12:11 Лирическое отступление: я открою вам секрет. Для менеджмента самое главное - это предсказуемость.
т.е. если вы программист и в этом месяце забабахали что-то гениальное, а в следующем месяце не забабахали ничего, вопрос стоит весьма остро - сколько вы забабахаете в следующем месяце?
Для менеджмента вы хреновый программист, потому что менеджер не может планировать ваш выхлоп, а у менеджера план и бюджет. Хороший программист (и любой другой работник) - предсказуемый, даже если он тупой.
т.е. если менеджер будет сравнивать гениального программера, который может сделает задачу за месяц, а может и не сделает, с тупым кодером, который гарантированно сделает ту же задачу за полгода, менеджер предпочтет тупого кодера.
Если над одним проектом работает несколько программистов/прочих работников, то обычно они организуются в команды/группы - руководителями которых (тим лидами), являются если не "гениальные", то, по крайней мере, достаточно опытные и не тупые программисты/работники. Эти руководители распределяет задачи между членами своих команд, координирует их выполнение и оценивает качество работы. Вся бюрократия и ежедневная суета при этом остаются на менеджеров, которые разгружают программистов от ненужных и не технических вопросов.Marmot писал(а):Бывают такие проекты, у которых время их выполнения тупым кодером проближается к бесконечности...Stanislav писал(а): Лирическое отступление: я открою вам секрет. Для менеджмента самое главное - это предсказуемость.
т.е. если вы программист и в этом месяце забабахали что-то гениальное, а в следующем месяце не забабахали ничего, вопрос стоит весьма остро - сколько вы забабахаете в следующем месяце?
Для менеджмента вы хреновый программист, потому что менеджер не может планировать ваш выхлоп, а у менеджера план и бюджет. Хороший программист (и любой другой работник) - предсказуемый, даже если он тупой.
т.е. если менеджер будет сравнивать гениального программера, который может сделает задачу за месяц, а может и не сделает, с тупым кодером, который гарантированно сделает ту же задачу за полгода, менеджер предпочтет тупого кодера.
Поэтому, у правильных менеджеров есть и те, и другие...