Access 2003
БД примерно 25 лет, различных объектов примерно 1000.

Я пытаюсь перевести разработку на модель, использующую GIT
И столкнулся со странным - GIT сообщает, что Access постоянно самостоятельно меняет имена переменных в модулях VBA.

То есть абсолютно без причины он может заменить "А" на "а", "TempIndex" на "tempindex", ну и всё в этом духе.
Как вы понимаете для Git это уже совершенно другой документ и всё становиться очень сложно ....

Изменяются документы в которых люди ни чего не изменяли и даже в редактор VBA не заходили.
То есть при следующем открытии базы имена переменных в произвольных модулях другие.

Я не нашел ни какой логики или системы в этих переименованиях.
Изучал интернет неделю и ни чего близко похожего не нашел в обсуждениях.

Может у кого то есть мысли что это за блинская обфускация и гребаное полиморфное сопротивление системам машинной разработки?
Какой вообще смысл в этом? Это же полноценная перекомпиляция модулей происходит.

Cheradak,

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

Скрипт на VB у нас разбирает/собирает и есть внутренний механизм, доступный для разработчиков после аутентификации чтоб прям в работающем файле импортировать/экспортировать любые объекты.

Группа разработчиков трудится, у каждого свои задачи.
Механизм полной и частичной сборки/разборки/добавления/вырезания при массовом автоматическом обновлении приложения на местах отлажен.
Локальных таблиц нет.

booby,

Option Explicit

alecko,

речь идет о переменных в функциях и процедурах
у нас, слава богам, ни кто ещё крышей не поехал публичные переменные именовать в стиле "А" или "М"

Сегодня вылезло в Git как Access SELECT на Select поменял в запросе который никто не редактировал 100% ....

Я вас уверяю - это не мы меняем. И это не наши опечатки и их последствия.
Я понимаю, что это просто бред какой-то, но объективно вот наблюдаю ...

sdku,

Это конечно не по теме, оффтоп и флейм, но прежде чем писать посты типа Вашего, потрудитесь всё же понять про что топик.
Перечитайте несколько раз если это необходимо. Я вот вижу Вы про Википедию знаете... Возможно и про Гугл слышали :)

Парадигма (модель) разработки вообще ни как не связана с конкретным ПО.
В данном случае я пытаюсь перейти на Git-Flow. Погуглите, Вам будет полезно.

Этим упоминанием я лишь описываю обстоятельства при которых проблема была выявлена.

sdku, если бы Вы читали внимательно и/или не были бы так глупы и невежественны, то не могли бы не обратить внимание на то, что про БД тут речь вообще не идет.

Выше русским по белому написано, что локальных таблиц нет. Это подразумевает, что используются только формы, отчеты, запросы и макросы.
Access используется как чистый FrontEnd, браузер для CRM/ERP, бизнес логика которого реализована на удаленной СУБД Postgres, если Вам вдруг это интересно.

alecko, спасибо!
Там вроде бы должно только предлагать замену, но я, на всякий случай всё выключил, что нашел ...

Посмотрим что будет.

booby, это, кстати, интересное предположение, но я по серьезному обратил внимание на это явление, когда работал над опасными функциями в локальной учетке с просто физически отсутствующим модулем обновления.
То есть ни кто кроме меня там менять ни чего не мог.
Вот тут то я и насторожился :)

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

Но всё оказалось гораздо страннее, загадочнее и таинственнее.

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

От себя могу сказать, что если от выработанной методологии не отступать, в моём случае Git-flow, то разрабатывать становиться ОЧЕНЬ приятно и удобно. Даже если работаешь один.
Нужно убедить себя, что единицей твоей работы является точка в ветвях Git, а не .mdb/.accdb (который можно собрать одним кликом сразу после чек-аута)
И всё сразу встаёт на свои места.

Когда есть возможность объявить новый бранч и просто Черри-пиком надергать из ветвей нужные формы и модули и тут же откомпилировать в .mdb/.accdb первой версии, то разработка прям резко ускоряется. Да чего уж там - это круто :)

Правда что делать если таблицы локальные и прям обязательно в этом же файле, я не готов сказать.
Как вариант просто держать в соседнем.

Serg197311, Git работает с текстовыми файлами (так то со всеми, но нормально с текстовыми, не будем сейчас вникать ...)

В моём случае это папка с 1003 файлами на этот час.
Это Модули, Формы, Запросы и Отчеты.
Макросы по историческим причинам лежат в пустом шаблоне .mdb в копию которого потом собирается нужное.
Нет ни каких причин не копировать их в txt, просто мы так не делаем. Их всего 8 и больше не будет.
Таблиц у нас нет.
Сейчас борюсь чтоб прекращали использовать кастомные атрибуты БД и шаблон не приходилось менять каждый месяц.
По идее их также можно просто в txt копировать, но в нашем случае это глупо (СУБД Postgres), это просто алогичная похмельная блаж отдельных разработчиков.

Сборка/разборка занимает 1-3 минуты. Всё очень удобно.

Только вот эти рандомные замены регистра переменных кровь слегонца пьют создавая псевдоколлизии при слияниях ветвей Git :)

alecko, у нас то заказчик всегда 1 (один) :)
И СУБД всегда одна и та же :)
Даже от стиля оформления отходить не благословляется - тут же по шапке прилетает.
Так что у нас это прямо ОЧЕНЬ оправдано.

Serg197311, Вы просто, совершенно напрасно, не знакомы с Git и методологиями разработки в нем :)
Почитайте ...
Есть высокий шанс, что Вы потом даже папку со своими домашними заметками и рецептами будете строго под Git держать :)

Модули "портятся" (произвольно меняются имена переменных) когда они в собранном виде.
То есть после следующей разборки, для внесения в Git, мы получаем модуль с ДРУГИМИ переменными с точки зрения Git.
То есть это ДРУГИЕ модули хотя мы там ни чего не меняли, а зачастую и не открывали.

И это очень тревожно, так как Git'ом ведь дело не ограничивается - такой файл нельзя использовать например в системах автоматизированной сборки и тестирования!

В общем это диверсия какая-то фирмы Microsoft и Била Гейтса лично :)

Konst_One,
я не буду ёрничать и "тонко шутить" над Вашим заблуждением масштаба религиозного верования, просто скажу что ВСЕ файлы офиса это легко разбираемые на текстовые сущности стандартизованного формата.
И accdb/mdb в частности.

И да, именно такой сервер я и пытаюсь сделать. С автоматизированным тестированием, покером и куртизанками :)
Собственно я хочу сделать ровно тоже самое, что делают разработчики на компилируемых языках так как разницы не вижу вообще ни какой.

OlegPermRu,
Непосредственно для сборки из Git и разборки редактированных версий я использую два скрипта на vb. Один разбирает, другой собирает.
Их оригинал, с комментариями на немецком языке, я встречал ещё лет 20 назад :)

---------------
Для переноса компонентов между разработчиками используем форму где они выгружаются/загружаются. Такой же механизм используется при авто обновлении копий приложения на местах - модуль обновления смотрит что надо обновить и закачивает всё необходимое ещё до формы ввода пароля.