>> >> >> А че будет, ежли и правда ключ чему-то приравнять? :-)))
>> >> AM> не понял, ключ приравнять то конЭчно нельзя а вот группу можно
>> >> AM> получилось то что ты и хотел, те групповое присвоение полей в СО> ключе, это
>> >> AM> имелось ввиду ?
>> >> Дык группы присваивать я уже умею ;). А то было б непосредственно ключ
>> >> 🙂
>> VVS> Вот более непонятно отсутствие ошибки при использовании
>> VVS> ключей не от тех файлов в файловых операциях.
>> VVS> Типа SET(File1:Key,File2:Key) и т.п.СО> есть подозрение что File1:Key,File2:Key — это просто порядковый номер ключа
СО> SET(1,1) — Может работать…. Грубо и наверно не так.
СО> Хотя есть подозрение что в результате вынимается номер ключа….
Немножко не так.
На самом деле все достаточно просто: в данной форме оператора SET() второй параметр используется ТОЛЬКО для определения самой операции — «выставить указатель в ключе по полям данного ключа». А само значение этого второго параметра драйвером не используется. Поэтому в качестве второго параметра может стоять ЛЮБОЙ ключ. Все данные о рабочем файле и ключевым полям берутся из ключа, заданного в качестве первого параметра.
Другое дело, что выглядит это малость странновато и должно бы пресекаться на этапе компиляции. Хотя думаю, что знаю, почему компилятор не делает подобной проверки — в качестве параметров оператора SET() могут быть использованы рефералы на ключи. А их принадлежность какому-либо файлу можно определить ТОЛЬКО во время выполнения.
Кстати! В рамках данной темы поднимался вопрос о сравнении скорости работы цикла чтения записей прямо из файла или посредством View. Как показывает опыт (и не только мой), чтение через View практически НИКОГДА не бывает медленнее прямого чтения из файла. Но, во многих случаях, чтение через View быстрее прямого чтения из файла. Иногда — на порядок!
Основные преимущества по скорости у View в следующих случаях:
- использование фильтрации записей. Особенно, когда фильтр не имеет прямой поддержки со стороны ключей.
- использование порядка сортировки, отличного от имеющихся ключей.
- работа с SQL-таблицами.
Небольшое дополнение к первому пункту: при использовании фильтра, который не «ложиться» ни на один из имеющихся ключей, разница в скорости выборки будет тем больше, чем меньше кол-во записей, удовлетворяющих всем условиям выборки.