String or Memo

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Hello clalist,

c6ee ABC
Что предпочтительнее при объявлении полей в таблицах
string(1000)
или
Memo(1000)
(именно 1000 и более )
???

--
Best regards,
Хайсаров mailto:talgat@omsknet.ru

(Добавление)

А что ты хочешь, иногда одно, а иногда другое! Критерии давай!

--
С уважением,
SAN mailto:vgsan@yandex.ru

Предпочтительней Cstring ...

---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ# 75924439
Написал: ClaList(2)
Гость

Сообщение Гость »

- просветите, в чем предпочтительность Cstring ?
По-моему, если строка, то string - лучше:
она же не всегда текст, и при использовании Cstring, теряем
все, что после первого нуля...

С уважением,
Сергей zap277@softhome.net

Вот если не текст, тогда String. Но часто ли это бывает?

Для Cstring не нужно задавать Clip. Len(CString) даёт реальную длину строки. Процедуры WinAPI зачастую хотят именно Cstring. А
вообще, конечно, дело вкуса... А Memo - это архаизм, ещё от старых версий, с ним куча проблем - не работают вырезки Memo[M:N], нет типа
данных &Memo ...

---------------------------------------
C уважением,
Юрий Философов
Предпочтительней Cstring ...
Не всегда.
У меня в C5 наблюдалась следующая ситуация: при использовании в ключах полей
CString позиционирование могло быть непредсказуемым.


------------------------------------------------------------
Igor Gubin (igor@quantor.com)
Quantor-Soft Metall
Phone/Fax: (+7 095) 234 4905
WEB: http://www.metaldata.info
http://www.metaldata.ru

(Добавление)

Ну, не надо так уж серьезно :)
Индексирование по CString очень часто спотыкается на
переприсваиваниях CString = String и на CLEAR(CString).
Что, в общем-то, и следует ожидать. Так что для индексируемых
полей предпочтительно String.
В данной теме замечание про индексирование вовсе не в кассу,
т.к. MEMO вообще не индексируется.

Кроме того, в ШВС (да и в ABC вроде как тоже) Update-процедуры
наличие изменений в форме определяется как
IF SAV::Record <> File:Record THEN PUT(File).
Т.к. MEMO не является частью RECORD, то изменение только
MEMO-переменной не приводит к обновлению записи...
Аналогично и с BLOB. Приходится вывешивать флаги изменений
или еще какой геморрой устраивать.

Лично для меня в 32-битном режиме прелести MEMO
не заметно. Другое дело - BLOB. "Безразмерность" такого
поля является существенным преимуществом.

С уважением,
В.Смелик

У меня в C5 наблюдалась следующая ситуация: при использовании в ключах полей
CString позиционирование могло быть непредсказуемым.

Ага... Было такое, но давно. А ещё в ключах концевые пробелы важны. Но всё это мелочи.

---------------------------------------
C уважением,
Юрий Философов

А вот и еще один вопрос: начиная с C55 (пока C6 не имеем) я всегда
использую CSTRING. Так же поля данного типа входят и в состав составных
ключей. Пока за полтора-два года косяков не наблюдал, но вот гложат
смутные сомнения, а вдруг...
Может Олег просвятит сообщество в этом вопросе

С уважением Мартюшев Леонид
mailto:leonid@opfr.komi.com

(Добавление)

Я в свое время достаточно подробно расписал, почему с полями CSTRING в
ключах возникают проблемы. Рихнуйте драйвера ручками :)

С уважением, Ставич Олег
Укрсиббанк г.Харьков

oldstav@ukrsibbank.com

Привет

Например, таблицы tps гораздо медленнее работают с cstring, чем с string

Михаил
Написал: ClaList(2)
Гость

Сообщение Гость »

Для Cstring не нужно задавать Clip. Len(CString) даёт
реальную длину строки.
Как-то уже в этой рассылке велись споры насчет скорости обработки
в Кларе STRING/CSTRING/PSTRING.
Если кто не помнит, напомню - самой быстрой является PSTRING.
STRING/CSTRING - практически одинаковы. Все зависит от реальных
обрабатываемых данных:
- если длина контента составляет <50% обьявленной длины строки, то
чуть быстрее работает CSTRING.
- если длина контента составляет >50% обьявленной длины строки, то
чуть быстрее работает STRING.

Len(Clip(String)) в реальных приложениях будет работать
практически с такой-же скоростью, что и Len(cString).

Str = Clip(Str)
cStr = cStr
Str = cStr
cStr = Clip(Str)

Все эти операторы будут работать практически с одинаковой
скоростью. А вот операторы Str = Str или cStr = Str будут
работать быстрее.
Процедуры WinAPI зачастую хотят именно Cstring.
Ну, не так уж часто приходится пользоваться WinAPI, что-бы
ради этого менять Str на cStr.
Тем более, что всегда можно воспользоваться временными cStr.
А вообще, конечно, дело вкуса... А Memo - это архаизм,
ещё от старых версий, ...
Зря, имхо! На сетевых приложениях позволяет значительно
уменьшить трафик, в отличии от использования вместо них String/cString.
с ним куча проблем - не работают вырезки
Memo[M:N]
Это - проблемы!?
Ну, батенька, Вы обленились, однако!:))
А если серьезно, то советую посмотреть как велась
работа с MEMO-полями в шаблонах старенькой досовой 2-ойки.

loc:Notes STRING(SIZE(FILE:Notes)),OVER(FILE:Notes)

И делай теперь с этим Notes, что душа пожелает!
... , нет типа данных &Memo ...
Ну так и &BLOB, можно считать, нет - применительно к файлам.
А если так уж необходимо, то используй вышеописанный метод
работы с MEMO-полями через перекрытие их строками -
&STRING прекрасно работает!

Единственная проблемка при использовании MEMO/BLOB-полей -
не забыть-бы про их обработку вне шаблоных процедур!

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com

Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)

&Blob есть, не надо. И я даже иногда использую. А вот Memo перестал. Ну не устраивает он меня...

---------------------------------------
C уважением,
Юрий Философов

Я имел в виду, что не работает FILE{PROP:BLOB,n}.
Точнее - работает, но возвращает неправильный реферал.
Аналогично и с BLOB. Приходится вывешивать флаги изменений
или еще какой геморрой устраивать.
Вах-вах! Это с каких пор такое безобразие творится
в любимых ШВС!?
Если трудно посмотреть шаблоны, то посмотри хотя-бы
в сгенеренный текст - MEMO-поля проверяются вместе
с буфером записи.
А вот BLOB, действительно, не проверяется.
Хотя, имхо, понятно - ведь он может быть приличных
размеров - получаем выделение лишней памяти под буфер
прежнего значения + тормоза при сравнение больших
обьемов. Намного проще программисту самому отслеживать
изменение BLOB-полей. Тем более, что они не так уж
часто и меняются. Особенно - в обычной форме изменения записи.
Лично для меня в 32-битном режиме прелести MEMO
не заметно. Другое дело - BLOB. "Безразмерность" такого
поля является существенным преимуществом.
Безразмерность не всегда нужна. Довольно часто бывает
нужно доп.место в размере порядка 1Кб. Ради этого
возится с BLOB, имхо, не стоит.

Может я просто привык, но такие дополнительные обьемы
предпочитаю хранить именно в MEMO-полях.
Особенно актуально для сетевых приложений - при отображении
в таблице таких файлов, значения из MEMO-полей, обычно,
не используются - можно не "тащить" лишние килобайты через сеть.
А вот при использовании строк прийдется "тащить" через
сеть ВСЮ запись.

=============================
С уважением, Олег А. Руденко

(Добавление)
А вот BLOB, действительно, не проверяется.
В какой-то версии был введен и контроль BLOB полей. Но кажется это было в
АВС ;)
В кишки по этому поводу не заглядывал, но думаю, что это сделано через
CRC32.
А вот при использовании строк прийдется "тащить" через
сеть ВСЮ запись.
Это можно решить связями 1 : 1

WBR, Nick Tsigouro Mailto:N.Tsigouro@mtu-net.ru

Т.е., ты имеешь в виду, что коммент можно вынести
из записи в отдельную таблицу и при необходимости
делать из нее выборку?!
Если так, то - уволь! - делать ручками то, что прекрасно
работает при использовании MEMO!
И самое главное - работает БЕЗ какого либо доп. кодирования!

=============================
С уважением, Олег А. Руденко
Если так, то - уволь! - делать ручками то, что прекрасно ...
Какими ручками? Завязываешь или не завязываешь в файловую схему доп. таблицы
и все. И речь не о комменте. Таких полей м.б.много. Например запись с
вариантами.
... работает при использовании MEMO!
Я бы еще понял, если бы ты аппелировал к нестабильности структуры БД, и что
если все запихать в МЕМО то можно разные версии поддерживать и
перекодировать на лету без конвертирования файлов.
И самое главное - работает БЕЗ какого либо доп. кодирования!
Ну да? И даже OVER прописывать не надо ? ;) А какже ты управляешь выборкой
этого МЕМО - когда надо подгружать сетку, а когда не надо?

WBR, Nick Tsigouro

(Добавление)
Какими ручками? Завязываешь или не завязываешь в файловую схему доп. таблицы
и все. И речь не о комменте. Таких полей м.б.много. Например запись с
вариантами.
Это будет работать ТОЛЬКО для бровзов. Хотя, с этим, как
я уже писал, прекрасно справляется и стандартный VIEW.
Кроме этого, это не будет автоматом работать в ручном коде.
Ну да? И даже OVER прописывать не надо ? ;-) А какже ты управляешь выборкой
этого МЕМО - когда надо подгружать сетку, а когда не надо?
Про работу VIEW с MEMO-полями я уже ответил в одном из
писем по данной теме.
Там-же я упомянул и шаблоны, которые генерят все необходимое
для комфортной и удобной работы с MEMO-полями.
Как один раз написал их еще для C50, так с тех пор и
не менял - можно уже считать, что все делается автоматом:))

=============================
С уважением, Олег А. Руденко

(Добавление)
В какой-то версии был введен и контроль BLOB полей. Но кажется это было в
АВС ;)
Не проверяются ... Приходится в запись добавлять поля типа DateChanged и TimeChanged и обновлять вместе с Blob.
... не используются - можно не "тащить" лишние килобайты через сеть.
А вот при использовании строк прийдется "тащить" через
сеть ВСЮ запись.
Для этого есть специальный оператор в Кларион (Nomemo), но кто его использует? И насколько он поддерживается шаблонами?

Да, и ещё. Memo НЕ ПОДДЕРЖИВАЕТСЯ SQL - акселераторами, о чём дальше говорить?

---------------------------------------
C уважением,
Юрий Философов

(Добавление)
Да, и ещё. Memo НЕ ПОДДЕРЖИВАЕТСЯ SQL - акселераторами, о чём дальше
говорить?
В C6 в SQL акселераторах появилась поддержка BLOB полей.

Andrew Myalin
andrew@arsis.ru
http://mavcla.arsis.ru (MAV Direct ODBC)
Yahoo group: clarion@yahoogroups.com

BLOB - да, и это замечательно. Но не Memo...

---------------------------------------
C уважением,
Юрий Философов

(Добавление)
Для этого есть специальный оператор в Кларион (Nomemo), но
кто его использует?
Я его АКТИВНО использую! Мои шаблоны умеют автоматом
генерить для каждого (или заданного) файла словаря
процедуру быстрой выборки по заданным ключам.
По-умолчанию, NOMEMO там включен. Если надо "утянуть"
запись с MEMO-полем, то просто задаю в вызове параметр.
И насколько он поддерживается шаблонами?
На все 100% (или почти:))! Если кто не знает, то по-умолчанию VIEW
не "тянет" вместе с записью и её MEMO-поля.
Для того, что-бы VIEW считывал и MEMO-поля, достаточно
указать их в списке "горячих" полей или, если используется
ручной код, в операторе PROJECT.
Да, и ещё. Memo НЕ ПОДДЕРЖИВАЕТСЯ SQL - акселераторами,
о чём дальше говорить?
И что!?
Я думал, что после недавних бурных и довольно познавательных
обсуждений перевода прог на SQL-сервера, большинство поняло,
что для НОРМАЛЬНОГО перевода просто НЕОБХОДИМО, в большинстве
случаев, перепроектировать, как минимум, словарь БД!
Кроме этого, для ЭФФЕКТИВНОЙ работы переведенной проги под
SQL-сервером, в большинстве случаев, НЕОБХОДИМО менять не
только шаблоны, но и переписать часть ручного кода!

Именно на этих этап ОЧЕНЬ ПРОСТО заменить MEMO-поля на
соответствующие SQL-типы.

=============================
С уважением, Олег А. Руденко

Ага. Так и сделал. Причем почти не менял саму Апп. Правда не все еще
работает, как надо. Почему-то при установке фильтра по месяцу все ОК,
а по дню - таблица при нажатии кнопки вниз гонит повторы строк. Если
ставить стандартный QBE - то все ОК. Где-то сам нахомутал.

--
Best regards,
gorky mailto:gorky@sv3.net.ua
Написал: ClaList(2)
Ответить