aleksey_sqlкак оно используется в приложении я могу понять ТОЛЬКО из выбирающихся данных. данные выбираются разные (поле filter у них разное и substr count не всегда = 1... поэтому собсно я и смотрел в сторону битовой маски).
Протрассировать запросы flextracer'ом также не удалось. Вышибает трейсер на этапе запросов связанных с этими табличками с полем filter :)

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

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

... у меня ваще пока что, такое осчущение, что в это поле складывается конкатенация обыкновенных переменных, в смысле в 8/16/32/64 бита... за каким-то лешим.

Если ЭТО не так, и каждая чиселка строкового представления - соответствует нормальному биту (0/1), то весь набор строковых функций - Вам в помощь. Только я по-прежнему НЕ представляю КАК поле длинной 1024бита может связываться с полем длинной 1920бит...

"Что-то не так в датском королевстве".

miksoft,

так о том и речь! По какой "части"? Ответ: смотреть исходник или должно быть известно априори (об чём автор - молчит). Есть другой ответ?

Arhat109,

просто, если оно "сначалу" - отрезаешь лишнее с конца... а ежели с конца - то начало режешь и тупо сравниваешь.

НО! Как показано - 1024 и 1920 - наибольшая длина... в примерах значительно меньше и утверждается - разная... и?

вывод напрашивается: смотреть исходник.

aleksey_sql,

А не надо шифроваться. Вы бы сразу описали задачу "как есть" - не было бы 2-х страничного гадания на кофейной гуще. Ладно вам своё время не жалко... но вам отвечают люди - далеко не безработные, ваще-то.