Может ли одна база 1с на SQL работать одновременно на двух разных серверах 1с (разные платформы)?

Может, но только один раз.

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

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

(0) может.

Тока если режим совместимости снят, то работать не будет - таблички разные, в большинстве случаев в разных релизах

8.3.9 и 8.3.13, к примеру

ну и механизмы нумерации не будут корректно работать, если 2 сервера 1с будут раздавать номера

(0) Да, может! Если она РИБ :)

А мне было бы интересно для какой задачи надо так.

может, но можно разных интересных приколюх словить. да та же самая нумерация объектов емнп.

(9) Ыыы...  лучше не спрашивай. Это же Обфускация
Лучше отвечай коротко - "Да" или "Нет". иначе придётся объяснять что такое кластер и как в нём сервера взаимодействуют :)

(9) могу предположить, что для тестирования поведения базы на разных релизах. например 8.2 и 8.3

(уходя) Вы бы, для ради приличия что ли, переспросили бы у автора про "различные платформы" - насколько они "различны".

(8) >  Если она РИБ.

РИБ - это разные базы (в терминах 1С - узлы), а не одна.

Можно, если базу 1С прописать два раза в кластере. При этом наблюдал интересный глюк: регламентные задания отрабатывали 2 раза ))

(0) Технически работать может. Но корректная работа не гарантируется.

Такое можно, но не для работы.
В моем случае такое понадобилось по следующей причине:
1. боевая база работает на сервере без ключа "-debug" (так быстрее);
2. случились какие-то глюки на серверной стороне, которые на копии не воспроизводились;
3. включать "-debug" - категорически нет, там много всего работает, а без перезагрузки сервера 1С это никак;
4. решение: есть сервер для разработчиков, там и опыты проводить (версии конечно же одинаковые);
5. риск потерять базу минимальный - по причине "правильного" резервного копирования;
6. зарегистрировал на другом сервере, вроде все работает... серверная отладка... поиск глюка... ура, исправлено.

вот как-то так.

точка с запятой идентифицируется как код?

есть точка с запятой;
нету точки с запятой.

(0)может... но только если структура хранения для обои платформ совпадет... и да, если из обоих баз будут менять данные - скажи прощай нумераторам... а так-же будут другие проблемы с данными.

(13) Какое это имеет значение. Желание (0) реализуемо, но непременно приведет как минимум к неконсистентности данных, а как максимум к разрушению базы данных.

Все сервисы (список ниже) живут внутри кластера. При попытке работать с одной базой данных каждый из кластеров будет задействовать свои сервисы. Рано или поздно неизбежно возникнет конфликт сервисов между собой. Самые частые - конфликты нумерации объектов, блокировок (всех видов), времени, заданий. Рано или поздно база накроется женским половым органом.

Блокировок объектов
Блокировок кластера
Времени
Журналов регистрации
Заданий
Нумерации
Полнотекстового поиска
Пользовательских настроек
Сеансовых данных
Транзакционных блокировок
Управления предметами отладки
Работы с внешними источниками данных через ODBC
Сервис лицензирования
Сервис фонового обновления конфигурации базы данных
Сервис внешнего управления сеансами
Сервис работы с внешними источниками данных через XMLA
Сервис тестирования
Сервис повторного использования сеансов
Сервис нумерации таблиц и полей базы данных
Сервис мониторинга счетчиков потребления ресурсов

(14) Распределенная Информационная База (ед.ч.), единая система (ед.ч.)
Да, в терминах 1С это несколько "информационных баз 1С:Предприятие (узлов)".

(20) Да, да, конечно. полностью с Вами согласен - кластер серверов может корректно работать только с одним сервером 1С. Иначе всё накроется медным тазиком.

Осталось только найти в вопросе автора слово "кластер" во фразе "на двух разных серверах 1с".

Мне кажется кто-то перевозбудился...

Это только кажется. Креститься не пробовал? :)

пробовал, работает, но начинаются проблемы с нумерацией.

гуиды и коды формируются на стороне сервера 1с, поэтому вводить данные можно только с одного сервера.
дргузи проблем вроде нет

(27) Насчёт GUID я бы не волновался - десяток лет работы базы РИБ подтверждают генерирование уникальных GUID не только в пределах одной базы.

(28) у тебя одна база в нескольких кластерах?

(29) Нет, у меня несколько распределенных баз, которые состоят из нескольких узлов, которые между сеансами обмена данными функционируют как автономные базы и генерируют GUIDы автономно и независимо друг от друга. Я ответил на Ваш вопрос?

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

Остаётся только определиться с исчезающе малой вероятностью того, что сервера 1С, чисто теоретически, могут одновременно сгенерировать два одинаковых GUIDа... :(

Особенно весело работают регламентные задания в приведенной ситуации.

(23) > Осталось только найти в вопросе автора слово "кластер" во фразе "на двух разных серверах 1с".

Достаточно включить голову, прочитав фразу "разные платформы".
Не бывает двух серверов разных версий в одном кластере. Это технически невозможно.

(33) Sorry. Я включил голову. Признаю ошибку, был не прав. Это был сарказм. Спровоцированный Вами :)

Осталось включить голову Вам и посмотреть так, как я это увидел:

"Рано или поздно неизбежно возникнет конфликт сервисов между собой." - это абсурд. Я понимаю, что Вы хотели сказать, но то, как и что Вы сказали - это абсурд.

Конфликты возникают не "между" сервисами - изначально (первоначально) конфликты возникнут в данных информационной базы, что в свою очередь приводит к неверной работе сервисов (это вторично). Но конфликта между сервисами - его нет. Т.е другими словами, сервисы будут работать и итог их "совместной" работы, рано или поздно, разрушит данные информационной базы.