key programming immo tools emergency start device программаторы ключа заводилки Кодграббер штатных охранных систем, toyota, lexus, subaru.

ВОПРОСЫ ПО CRONOS,ДР.БАЗАМ И ПРОГРАММАМ

putnik5

Well-Known Member
Добрый день, подскажите как из CSV файла сделать банк кроноса. Пытался сам разобраться, не получилось, кронос почему -то не видит этот файл. Заранеее благодарен
2.png
 

Вложения

  • 43.6 KB Просмотры: 26

r1gan

Member
Добрый день, подскажите как из CSV файла сделать банк кроноса. Пытался сам разобраться, не получилось, кронос почему -то не видит этот файл. Заранеее благодарен
Добрый день!
Если файл.CSV небольшой, то откройте его из под экселя. Сохраните, потом файл.XLS грузите в Кронос.
 

r1gan

Member
Приветствую всех, разбираюсь с кроносом, не подскажите ли как можно реализовать удаление в поле первой цифры, если она равна 8 или 7? ЗАРАНЕЕ СПАСИБО! Еще скачал мануал по формулам а он пустой, не поделитесь ссылкой?
Порой при редактировании телефонов всё не так очевидно, Сначала нужно отрезать +, скобки, потом сделать ряд проверок.
Я бы добавил проверку на длину поля и на коды сотовых операторов.
Если длина больше 10 и после 7/8 идут 900, 901, 910, 953, 977, 960 и т.п., то это сотовый... и так далее
А чтобы открыть мануал с формулами нужно изменить настройки безопасности в свойствах файла chm. В Интернете об этом написано.
 

лёва

Well-Known Member
Добрый день, подскажите как из CSV файла сделать банк кроноса. Пытался сам разобраться, не получилось, кронос почему -то не видит этот файл. Заранеее благодарен
Посмотреть вложение 24693
В свойствах файла (открыть как) выставьте "тхт" и Кронос его увидит.
У вас стоит таблица, естественно, что он его не видит. CSV это ТХТ, с разделителями.
 

rss773

Member
Добрый день.

Помогите пожалуйста разобраться. Осваиваю Глобальный поиск. Вопрос создания базы глобального поиска и подключения к ней необходимых баз решен. В дальнейшей эксплуатации возникла следующая проблема: при одновременном запросе на поиск по ФИО и дате рождения ищет всех людей с такими ФИО и всех людей с такой датой рождения, даже если эта дата рождения относится к совершенно другим ФИО. Логическую связку "И" использую. Версия Кроноса 5.0.11003.
 
Последнее редактирование:

Саша78

Well-Known Member
Добрый день.

Помогите пожалуйста разобраться. Осваиваю Глобальный поиск. Вопрос создания базы глобального поиска и подключения к ней необходимых баз решен. В дальнейшей эксплуатации возникла следующая проблема: при одновременном запросе на поиск по ФИО и дате рождения ищет всех людей с такими ФИО и всех людей с такой датой рождения, даже если эта дата рождения относится к совершенно другим ФИО. Логическую связку "И" использую.
Проверьте настройки таблиц глобального поиска настройки соответствий
при поиске И стоит по умолчанию

Если у вас в БАЗЕ1 есть поле ФИО и поле "дата рождения" и таблице на них есть соответствие - отбор будет на одновременно выполняемых 2 условиях (проверено)
Если у вас в БАЗЕ1 есть только поле ФИО отбор будет на ФИО какую бы дату вы не задавали

Глобальный поиск подразумевает поиск по большому количеству разноформатных баз и естественно структура у каждой своя:
где то есть ФИО +ДР
где то только ФИО
легко не что то заметить, легко ошибиться

Но я проверил Вашу ситуацию на своем массиве с глобальным поиском (>100 БД) все работает в т.ч. и через Интернет-компонент Кроноса
опять же при условии внимательной настройки таблиц соответствия
 

r1gan

Member
при одновременном запросе на поиск по ФИО и дате рождения ищет всех людей с такими ФИО и всех людей с такой датой рождения, даже если эта дата рождения относится к совершенно другим ФИО. Логическую связку "И" использую.
Всё верно. Вы задаёте два условия:
1.найти всех людей с нужным ФИО
2.найти всех людей с заданной датой рождения.
Он формирует два разных массива и отдаёт Вам.
Перепроектируйте (или откорректируйте) Глобальный поиск.

Я делал так: создавал в ГП таблицу ЛИЦО, внутри делал такие строки
1.Фамилия
2.Имя
3.Отчество
4.ФИО группой
5.Дата рождения
6.Год рождения

Проектировал таблицу соответствий.
Попробуйте на нескольких базах и поймёте логику работу ГП.

Многие сгружают в одну таблицу в ГП всё: ЛИЦО, АДРЕС, ТЕЛЕФОНЫ, ДОКУМЕНТЫ, ИНН, СНИЛС (всё говно разом).
Я разделял и да это *** как муторно и долго, зато результат релевантный. Но сейчас использую другой подход.
 

rss773

Member
Проверьте настройки таблиц глобального поиска настройки соответствий
при поиске И стоит по умолчанию
Сейчас сижу разбираюсь и экспериментирую. И как оказалось проблема несколько глубже, чем виделось в начале.

Ситуация такая. Есть некоторое количество исходных БД. Часть БД имеет поле ФИО и поле Дата рождения. Другие БД имеют поля Фамилия, Имя Отчество и поле Дата рождения.

Соответственно, в базе Глобального поиска сделаны поля:
- ФИО
- Фамилия
- Имя
- Отчество
- Дата рождения

Соответственно к указанным выше полям подключал только соответствующие поля имеющихся БД.

При поиске по сложному запросу заполняю поля ФИО и дата рождения. При внимательном анализе выдачи заметил, что действительно находятся соответствующие этим критериям записи, но... Попадает достаточное количество "мусора", где в выдаче есть искомая мною дата рождения и "левые" ФИО. И этот мусор с левыми ФИО идет из баз, в которых Фамилия, Имя и Отчество разнесены в отдельные поля.

Как избавиться от этого "мусора"?
 

rss773

Member
Всё верно. Вы задаёте два условия:
1.найти всех людей с нужным ФИО
2.найти всех людей с заданной датой рождения.
Он формирует два разных массива и отдаёт Вам.
Перепроектируйте (или откорректируйте) Глобальный поиск.

Я делал так: создавал в ГП таблицу ЛИЦО, внутри делал такие строки
1.Фамилия
2.Имя
3.Отчество
4.ФИО группой
5.Дата рождения
6.Год рождения

Проектировал таблицу соответствий.
Попробуйте на нескольких базах и поймёте логику работу ГП.

Многие сгружают в одну таблицу в ГП всё: ЛИЦО, АДРЕС, ТЕЛЕФОНЫ, ДОКУМЕНТЫ, ИНН, СНИЛС (всё говно разом).
Я разделял и да это *** как муторно и долго, зато результат релевантный. Но сейчас использую другой подход.
Спасибо за развернутый ответ.

Насколько я понимаю, сделано у меня все как у Вас. Непонятно, как в выдачу попадает мусор.
 
Последнее редактирование:

Саша78

Well-Known Member
Сейчас сижу разбираюсь и экспериментирую. И как оказалось проблема несколько глубже, чем виделось в начале.

Ситуация такая. Есть некоторое количество исходных БД. Часть БД имеет поле ФИО и поле Дата рождения. Другие БД имеют поля Фамилия, Имя Отчество и поле Дата рождения.

Соответственно, в базе Глобального поиска сделаны поля:
- ФИО
- Фамилия
- Имя
- Отчество
- Дата рождения

Соответственно к указанным выше полям подключал только соответствующие поля имеющихся БД.

При поиске по сложному запросу заполняю поля ФИО и дата рождения. При внимательном анализе выдачи заметил, что действительно находятся соответствующие этим критериям записи, но... Попадает достаточное количество "мусора", где в выдаче есть искомая мною дата рождения и "левые" ФИО. И этот мусор с левыми ФИО идет из баз, в которых Фамилия, Имя и Отчество разнесены в отдельные поля.

Как избавиться от этого "мусора"?
Все базы стараюсь делать и с ФИО и с разделенными ркеквизитами Ф И О
Если он только совмещенный то процент точности поиска падает
есть случаи когда имя имеет написание одинаковое с чьей то фаимлией например есть украинская фамилия Иван именно фамилия ну т.д.
а если еще при поиске использовать * то Петр* (вы подразумевали Петрук, Петров, Петрушевский) превращается в отчество Петрович и т.д.
Разделенные реквизиты дают (мое субъективное мнение) больше гибкости при поиске и идентификации информации
Советую Вам потратить время на разделение реквизитов, конечно если это будет не разовая акция по поиску информации а создание группы БД для глобального поиска на постоянной основе
Ну естественно нормализовать реквизиты (убрать лишение пробелы, "кириллизировать" случайные латинские буквы в ФИО и т.д. у каждого своя методика)
 

r1gan

Member
При поиске по сложному запросу заполняю поля ФИО и дата рождения. При внимательном анализе выдачи заметил, что действительно находятся соответствующие этим критериям записи, но... Попадает достаточное количество "мусора", где в выдаче есть искомая мною дата рождения и "левые" ФИО. И этот мусор с левыми ФИО идет из баз, в которых Фамилия, Имя и Отчество разнесены в отдельные поля.
Вы затронули самую глубокую тему. Поиск. Вы зрите в корень. Поймёте причину мусора - Вам откроется сакральное знание. Вы серьезно оптимизируете свой поиск и его результаты (особенно после того, как переделаете 90% всех имеющихся баз данных).
Первый момент: сложный запрос. Его использую в основном (т.е. в 99% запросов) только при поиске по одной базе, не в ГП, иначе время ответа увеличивается очень сильно (на более мощных серверах и машинах возможно будет пошустрее). Не вижу смысла использовать сложный поиск (запрос) в ГП.
Второй момент: Глобальный поиск. ГП - это уже своего рода сложный запрос.
Вывод: используйте простой запрос (поиск).
Оптимальный запрос выглядит так: указываете отдельно Фамилию (можно с маской), Имя (маска), Отчество (маска), Дату рождения.
Он падает в "оптимальную БД", где уже в отдельную таблицу вынесено ЛИЦО, в которой есть поля Фамилия, Имя, Отчество и Дата рождения. Есть такой термин нормализация БД и третья нормальная форма.
В других таблицах этой "оптимальной БД" отдельно лежат Адреса, Документы, Машины, Телефоны.
Теперь про мусор:
Особенно часто мусор появляется при поиске по старым базам гибдд, где в одной плоской таблице указаны два лица, собственник и, например, владелец по доверенности.
Кронос не может разделить собственника и владельца по доверенности. Вы ищете: Иванов Михаил Сергеевич. Он находит в поле собственник фамилию Иванов (Григорий Дмитриевич), а в поле владелец по доверенности находит (Кочетов) Михаил Сергеевич.
В целом - сложно без скриншотов понять причину Вашего мусора.
Скриншот соответствий ГП.
Скриншот Запроса.
Скриншот Мусора.
Так будет легче разобраться в его причинах.
 
Последнее редактирование:

s3d0v

Active Member
Коллеги, добрый день! Есть проблема с "Архивариус 3000", вер. 4.79/x32: выяснилось, что не индексируются архивированные mdb-файлы (Microsoft Access). Пробовал и zip, и 7z, даже gz с tar. Результат один и тот же: неупакованный mdb - индексируется, упакованный - выдает ошибку "Extract error".
1547190693513.png
Параллельно выяснилась одна особенность: mdb-файлы в принципе не хотят индексироваться 64-битной версией Архиварисуса, только 32-битной.
Простое решение, конечно, в том, чтобы использовать 32-битную версию на неупакованных файлах, однако, хотелось бы решить данную проблему правильно.
Кто-то сталкивался с подобным? Может, на других (ранних) версиях все было нормально?
 

r1gan

Member
не индексируются архивированные mdb-файлы
Добрый день!
Альтернативный вариант: если файлов mdb немного - вручную из mdb выгрузить в csv.
Если файлов много - автоматизировать, т.е. написать скрипт, который это сделает.
 

EmpireState

Well-Known Member
Добрый день, ребята!
Тут как-то проходила информация о связи двух баз посредством типа поля "Связь по полю".
Напомните, пожалуйста, как это грамотно реализовать.
Спасибо!
 

Саша78

Well-Known Member
База 1 есть поле ИНН
База2 тоже есть поле ИНН

В Базе1 делаем реквизит тип связь по полю

В Базе2 делаем реквизит тип связь по полю

Связываем их между собой
1-2.jpg

а в свойствах указываем связное поле в каждой из баз
1-1.jpg

Поля связные обязательно индексируем
По сути связь по полю это постоянно выполняемый запрос на поэтому она тормозит базу
Связные поля могут быть не полностью идентичны
Например
в Базе1 связное поле ФИО
в Базе2 связное поле Фамилия

Результаты (количество связных ИО) в таком случае будут отличаться в зависимости от того с какой стороны (Базы) зайдешь

Например если связное поле телефон
и в Базе1 он имеет формат +790999999999
в Базе2 формат 999999999

то со стороны Базы2 связь будет
со стороны Базы1 нет

также в связных полях можно применять размытие - ? *
например для телефона *99999*
для фамилии Петр*ч

связное поле также может быть множественным

Но индексация обязательна
Корректировка связного поля меняет результат
 

Вложения

r1gan

Member
проходила информация о связи двух баз посредством типа поля "Связь по полю"
Постами выше есть видео про множественные поля, там показано, как связывать несколько таблиц через "связь по полю".
 

zoral199

Active Member
Добрый вечер, не мог бы кто-то объяснить на пальцах, как прикрепить фото к базе в кроносе, поискал, пишут через формулу можно, даже указывают через какую, но все равно не понятно как-то
 

Саша78

Well-Known Member
Добрый вечер, не мог бы кто-то объяснить на пальцах, как прикрепить фото к базе в кроносе, поискал, пишут через формулу можно, даже указывают через какую, но все равно не понятно как-то
Синтаксис


ADDFILE ( Поле, Файл )
Аргументы

Поле – поле типа «Файл», заданное в формате <МнемокодБазы><НомерПоля>. Если указанное поле является множественным, после названия поля в скобках должен быть указан порядковый номер значения. Если он не указан, будет заменено содержимое первого файла в поле. Если этот номер больше, чем максимальное количество значений в множественном поле, в поле будет добавлено соответствующее количество новых значений.
Файл – строка, содержащая имя и путь к файлу. Адрес файла может задаваться в формате UNC (например, «\\Server\BD\TestPlus»).




Пример использования
Предположим, в множественном поле №15 базы ЛЦ хранятся 2 файла. 1-й файл имеет имя «Файл1» и содержит текст «Текст1», 2-й файл – имя «Файл2» и текст «Текст2».

@filename := «C:\Работа\Новый_файл.txt»;
@res := ADDFILE( ЛЦ15, @filename ); /* первое значение поля ЛЦ15 (файл «Файл1») будет заменено файлом «Новый_файл.txt», расположенным по адресу: «C:\Работа\» */

@filename := «C:\Работа\Новый_файл_2.txt»;
@res := ADDFILE( ЛЦ15 (2) , @filename ); /* второе значение поля ЛЦ15 (файл «Файл2») будет заменено файлом «Новый_файл_2.txt», расположенным по адресу: «C:\Работа\» */

@res := ADDFILE( ЛЦ15 (4) , @filename ); /* в четвертое (и третье, поскольку оно было пустым) значение поля ЛЦ15 будет помещен файл «Новый_файл_2.txt», расположенный по адресу: «C:\Работа\» */
 
Сверху