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)
String or Memo
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
- просветите, в чем предпочтительность Cstring ?
По-моему, если строка, то string - лучше:
она же не всегда текст, и при использовании Cstring, теряем
все, что после первого нуля...
С уважением,
Сергей zap277@softhome.net
Вот если не текст, тогда String. Но часто ли это бывает?
Для Cstring не нужно задавать Clip. Len(CString) даёт реальную длину строки. Процедуры WinAPI зачастую хотят именно Cstring. А
вообще, конечно, дело вкуса... А Memo - это архаизм, ещё от старых версий, с ним куча проблем - не работают вырезки Memo[M:N], нет типа
данных &Memo ...
---------------------------------------
C уважением,
Юрий Философов
У меня в 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. "Безразмерность" такого
поля является существенным преимуществом.
С уважением,
В.Смелик
Ага... Было такое, но давно. А ещё в ключах концевые пробелы важны. Но всё это мелочи.
---------------------------------------
C уважением,
Юрий Философов
А вот и еще один вопрос: начиная с C55 (пока C6 не имеем) я всегда
использую CSTRING. Так же поля данного типа входят и в состав составных
ключей. Пока за полтора-два года косяков не наблюдал, но вот гложат
смутные сомнения, а вдруг...
Может Олег просвятит сообщество в этом вопросе
С уважением Мартюшев Леонид
mailto:leonid@opfr.komi.com
(Добавление)
Я в свое время достаточно подробно расписал, почему с полями CSTRING в
ключах возникают проблемы. Рихнуйте драйвера ручками
С уважением, Ставич Олег
Укрсиббанк г.Харьков
oldstav@ukrsibbank.com
Привет
Например, таблицы tps гораздо медленнее работают с cstring, чем с string
Михаил
Написал: ClaList(2)
По-моему, если строка, то 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, что-быПроцедуры WinAPI зачастую хотят именно Cstring.
ради этого менять Str на cStr.
Тем более, что всегда можно воспользоваться временными cStr.
Зря, имхо! На сетевых приложениях позволяет значительноА вообще, конечно, дело вкуса... А Memo - это архаизм,
ещё от старых версий, ...
уменьшить трафик, в отличии от использования вместо них String/cString.
Это - проблемы!?с ним куча проблем - не работают вырезки
Memo[M:N]
Ну, батенька, Вы обленились, однако!:))
А если серьезно, то советую посмотреть как велась
работа с MEMO-полями в шаблонах старенькой досовой 2-ойки.
loc:Notes STRING(SIZE(FILE:Notes)),OVER(FILE:Notes)
И делай теперь с этим Notes, что душа пожелает!
Ну так и &BLOB, можно считать, нет - применительно к файлам.... , нет типа данных &Memo ...
А если так уж необходимо, то используй вышеописанный метод
работы с 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.
Кроме этого, это не будет автоматом работать в ручном коде.
Про работу VIEW с MEMO-полями я уже ответил в одном изНу да? И даже OVER прописывать не надо ? А какже ты управляешь выборкой
этого МЕМО - когда надо подгружать сетку, а когда не надо?
писем по данной теме.
Там-же я упомянул и шаблоны, которые генерят все необходимое
для комфортной и удобной работы с MEMO-полями.
Как один раз написал их еще для C50, так с тех пор и
не менял - можно уже считать, что все делается автоматом:))
=============================
С уважением, Олег А. Руденко
(Добавление)
Не проверяются ... Приходится в запись добавлять поля типа DateChanged и TimeChanged и обновлять вместе с Blob.В какой-то версии был введен и контроль BLOB полей. Но кажется это было в
АВС
Для этого есть специальный оператор в Кларион (Nomemo), но кто его использует? И насколько он поддерживается шаблонами?... не используются - можно не "тащить" лишние килобайты через сеть.
А вот при использовании строк прийдется "тащить" через
сеть ВСЮ запись.
Да, и ещё. Memo НЕ ПОДДЕРЖИВАЕТСЯ SQL - акселераторами, о чём дальше говорить?
---------------------------------------
C уважением,
Юрий Философов
(Добавление)
В C6 в SQL акселераторах появилась поддержка BLOB полей.Да, и ещё. Memo НЕ ПОДДЕРЖИВАЕТСЯ SQL - акселераторами, о чём дальше
говорить?
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)