String vs Memo
Gary Stephens
a Memo. According to the docs a string can contain 64K+ characters.
More than enough for my needs.
Opinions please.
Gary
Kevin Erskine
1st - they are stored as part of the record structure so...
SAV::CUS:Record = CUS:Record
Saves everything...
If using a MEMO - the memo is not part of the record Structure
there are other disadvantages to MEMOs also -- but....
CTRINGS are auto compressed now in TPS so same compression as what we used
to achieve with MEMOs...
I personally only use CTRINGS and NEVER use STRINGS.
Kevin
"Gary Stephens" <gas...@attbi.com> wrote in message
news:3D71889D...@attbi.com...
Doug
For the most part, CStrings are the way to go. Very few SQL databases
support memo's in the same manner that TPS does... so better to use cstrings
for portability reasons between different file formats.
TPS files do a fine job at compressing cstrings also, so the hd space is
minimal. I/O is also quicker when not having to deal with memo fields using
TPS files.
IMO, memos are only useful for storing very large amounts of text or when
you really are concerned about saving maximum storage on your hd (although
with 120gig+ drives, I can't see why anyone would be so concerned about the
slightly better data compression that you get from memo fields).
HTH,
Doug
"Gary Stephens" <gas...@attbi.com> wrote in message
news:3D71889D...@attbi.com...
Elli
I switched from a few memos to strings primarily because if i forgot
to clear the memo specifically along with clearing the record the memo
contents stayed in memory and were passed along to the next record i
created.
On Sat, 31 Aug 2002 20:25:17 -0700, Gary Stephens <gas...@attbi.com>
wrote:
Warm regards
Elli
CW5peB,TPS,Legacy , win98
Arnor Baldvinsson
On Sat, 31 Aug 2002 20:25:17 -0700, Gary Stephens <gas...@attbi.com>
wrote:
>What are the advantages and disadvantages of using a String versus using
>a Memo. According to the docs a string can contain 64K+ characters.
>More than enough for my needs.
Memos are not part of the record structure. In TPS files the maximum
size of the record structure is 14,000 bytes. That means that you can
have a max 14,000 byte string in it. OTOH, you can have 255 memos or
blobs in it as well as 14,000 byte record.
Best regards,
Arnór Baldvinsson
Icetips Software
San Antonio, Texas, USA
www.icetips.com
ar...@icetips.com
ICQ: 113314380
Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm
Roger Due
You need to ask a somewhat wider question: What database are you going
to use, now or in the future? If you have any intentions of using the
Btrieve driver for Pervasive SQL 2000i, then you WILL need to be aware
that there is a 4K limit on the record size IF you intend to use
CapeSoft's FM2 or SoftCreator's Data Converter (DC) to manage
upgrading record structure changes. Neither FM2 nor DC can determine
if the record structure has changed when the record size is greater
than 4K. If you have a record size greater than 4K and change the
record structure, you will corrupt that table the next time you write
to it, under these circumstances.
I recently became very aware of this problem and am busy converting
many CSTRING fields to MEMO fields in many tables to get the record
sizes under 4K. Fortunately, this conversion is not that big of a
deal, since it mainly involves changing the field definition in the
DCT. I was already using a TEXT box for user input on the forms for
these larger fields.
Before starting this project, I had studied many postings on these NGs
that pointed to the merits of using CSTRING instead of MEMO,
especially if one expects to use SQL in the future. But I don't ever
recall anyone pointing out this 4K record size problem when using the
Btrieve driver. In our situation, the Pervasive SQL 2000i with the
Btrieve driver makes a lot of sense at this stage. Many users on these
NGs and in private conversations have found Pervasive to be very
stable and trouble free on a wide variety of hardware under a wide
variety of configurations.
Hope this helps,
-- Roger Due
On Sat, 31 Aug 2002 20:25:17 -0700, Gary Stephens <gas...@attbi.com>
wrote:
>What are the advantages and disadvantages of using a String versus using
Doug
Are you sure about the 4k problem with SoftCreator's Data Converter (DC)?
I am aware of FM2's limitation of upgrading TPS files to Pervasive Betrieve
format when it exceeds the 4k limit. My understanding is that the design of
FM2 was based around checking for an invalid record declaration for
upgrading its files.
Mismatching record declarations larger than 4k won't return an error code in
Betrieve and therefore causes FM2 to not properly update its file structure.
I have been planning on switching to SoftCreator's Data Converter for this
reason alone. I thought DC's design was different and allowed for upgrading
record structures above 4k. Don't ask me how their product does it, but I
recall that being the case. Maybe someone else who uses DC can chime in on
this. I certainly hope you are wrong on this one.<g>
Doug
"Roger Due" <ra...@thuntekNOSPAM.net> wrote in message
news:t3r4nukcn7pqr2892...@4ax.com...
Roger Due
The following is the email I sent to Vasiliy Goncharenko recently to
verify this 4K issue. I surrounded his answer below so that it is easy
to spot. I had a few more email exchanges with him to see if there was
any other possible solution to get around the 4K record limit for
Betrieve, but there seems to be none. At this point, what is not clear
to me is whether it would be possible for SV & Pervasive to work
together to solve this Btrieve limitation. It certainly would be nice
if they could! In the meantime I am switching the larger cstring
fields to memo fields where I have run into this 4K limitation. Tony
Tetley indicated to me that they use the memo field without problems
with Btrieve,
If anyone knows of a good solution to this problem, please let us
know.
-- Thanks, Roger Due
Hi, Roger,
Friday, August 23, 2002, 4:32:13 PM, you wrote:
> I have DC version 1.75. At the moment, I am still using the TPS files for
> development, but will be switching to the Pervasive SQL 2000i database
> using the Btrieve interface.
> Recently I understand that if I were to use FM2 from CapeSoft that FM2
> would not work properly if any of my tables (files) were greater than 4K
> bytes in size. Apparently the Btrieve interface does not identify if the
> record structure changes if the size of the record is greater than 4K.
> QUESTION: Does your DC 1.75 (or later?) properly handle record conversions
> using the Btrieve interface to Pervasive SQL 2000i WHEN table records are
> larger than 4K??? Please explain your answer. I currently have many that
> are and expect to have some that might even be as large as 32K.
> QUESTION: Is there a later version than 1.75 of DC?
> -- Thanks, Roger Due
===ANSWER===========================================
The same situation with DC - DC can't recognize structure changes in
files bigger than 4kbytes.
Regards,
Vasiliy Goncharenko.
======================================================
Doug
Well, I guess you have ruined my day.<g>
I was planning on taking the same file migration path to Betrieve, and now
this may complicate things.
I may even have to consider the longer route of going to SQL and bypassing
Betrieve altogether.
However, there must be a less glamorous, semi-automatic way of upgrading
large file declarations.
Maybe we should start another thread to see how others have gotten around
this situation?
I only have 2 or 3 files in my entire 200 file dictionary that exceed this
4k limit. I'm sure there must be a way to upgrade these files without
talking a customer through complete manual steps.
Does anyone know?
Doug
"Roger Due" <ra...@thuntekNOSPAM.net> wrote in message
news:6mm5nug9231oj4q68...@4ax.com...
Bo Schmitz
The less glamourous semi-automatic way?
You asked<G>.
Solution 1 (easiest)
Use the ini file to store a value (version number etc),
and in new compile on startup of main exe, compare
to new value and trigger rebuild of all (or select) files.
You can also use this feature to reset all browses to
default sizes on a new build.
Solution 2 (better, more work)
File design theories from other programming
languages due to limitations dies hard<G>
Split the file to stay under the record size limits.(one to one)
2nd (3rd etc) file only needs primary key.(in most cases)
Careful file design keeps critical and most used data and
keys in the main file. Split forms. Stuff long strings in the
extra files. Get the extra data only when you need it, keeps
it lean, mean, and fast.
FM2 picks it up like a champ. Change a field size one byte
to trigger key-only changes in the file structure with FM2.
(I like to think it still qualifies for Lazy Programmers<VBG>)
--
Bo Schmitz
Comsoft7
=========
"Doug" <MailNOS...@mindspring.com> wrote in message
news:3d72...@news.softvelocity.com...
Doug
> Solution 1 (easiest)
> Use the ini file to store a value (version number etc),
> and in new compile on startup of main exe, compare
> to new value and trigger rebuild of all (or select) files.
> You can also use this feature to reset all browses to
> default sizes on a new build.
>
What exactly do you imply when you say a rebuild of all files? My app
already knows what the prior version was and what the new version will
become. However, I don't know how that helps me. Some customers could be
on versions with different record declarations of the same file. Are you
implying that FM2 could reconstruct the file if it is forced to do so? I'm
a bit confused, but this option sounds promising to me at least. Could you
please clarify?
Your solution 2 is definitely the lazy man out<g>... I'll probably consider
another file format before I go that route.
Thanks,
Doug
Kurt Pawlikowski
I believe it's 15,000... {'-)
Regards,
kurtt
Kurt Pawlikowski
The Pinrod Corporation
ku...@pinrod.com
(773) 284-9500
http://pinrod.com
Kurt Pawlikowski
One thing I didn't see mentioned: You can't use a memo as a key.
Another thing: Accessing a memo usually requires another disk read
operation. Might be a factor in searching...
Regards,
kurtt
Kurt Pawlikowski
The Pinrod Corporation
ku...@pinrod.com
(773) 284-9500
http://pinrod.com
Bo Schmitz
Been awhile since I dug into FM2, cuz normally it works so good.
I have a template that I autoincrement when there are changes
that require some action on the apps part. It examines the ini file
for a value, triggers the events if different, and then stores the new
ini value. In essence a run once thing on the updated app.
Then you can include anything you want in that loop, call
an external convert program, force autobuild from FM2(hopefully)
clear ini browse default settings, etc.
#!---------------------------------------------------------------
#!---------------------------------------------------------------
#TEMPLATE(RWSZ,'Reset Window Sizes in INI file for each Procedure'),FAMILY('ABC')
#!---------------------------------------------------------------
#!------------------------------------------------------------------
#EXTENSION(ResetWindowSizesIni,'Reset Window Sizes in INI file for each Procedure')
#!---------------------------------------------------------------
#! Updated July 19,2002 by Bo Schmitz, Comsoft7
#! Now uses the ini file to store a variable
#! for resetting window sizes.
#! Updated to an Extension template for the Frame.
#!
#! Original submitted on Newsgroups from Mark Riffey, GraniteBear
#!
#RESTRICT
#IF (UPPER(%ProcedureTemplate)= 'FRAME')
#ACCEPT
#ENDIF
#REJECT
#ENDRESTRICT
#!---------------------------------------------------------------
#DISPLAY ('')
#BOXED('What am I doing?')
#DISPLAY ('Inserts code into the Frame INIT() method to')
#DISPLAY ('delete all the screen size memorization stored')
#display ('in the program ini file for each procedure')
#display ('This is normally used when a new release of your')
#display ('program is issued and that new release introduces')
#display ('altered screen sizes.')
#display ('')
#PRompt ('Version or Build (@S10) to reset ini',@s10),%RWSZFlag,REQ,DEFAULT('1')
#display ('')
#ENDBOXED
#!---------------------------------------------------------------
#AT(%WindowManagerMethodCodeSection,'Init','(),BYTE'),PRIORITY(7501)
! *** Code by RWSZ Template ***
INIMgr.Init('%INIFileName')
IF (INIMgr.TryFetch('RWSZ','RWSZFlag') = %RWSZFlag)
#! all is ok, on my merry way.
ELSE
#!
#!Add any other one time code to execute here.
#!
!clear all the window sizes
#FOR(%Procedure)
INIMgr.Update('%Procedure','maximize','')
INIMgr.Update('%Procedure','xpos','')
INIMgr.Update('%Procedure','ypos','')
INIMgr.Update('%Procedure','height','')
INIMgr.Update('%Procedure','width','')
#ENDFOR
MESSAGE ('Because you have installed a new release, the program has reset the
"memorized" screen sizes and locations so that' |
& ' you don''t "lose" any new features that would appear on screens that
changed in size. Any screen size locations that you' |
& ' change will be remembered until your next
upgrade','Warning',icon:question)
INIMgr.Update('RWSZ','RWSZFlag',%RWSZFlag)
END !if
! *** End Code by RWSZ Template ***
#ENDAT
--
Bo Schmitz
Comsoft7
=========
"Doug" <MailNOS...@mindspring.com> wrote in message
news:3d73...@news.softvelocity.com...
Arnor Baldvinsson
On Mon, 02 Sep 2002 13:13:11 -0500, Kurt Pawlikowski
<ku...@pinrod.com> wrote:
> I believe it's 15,000... {'-)
Yes, you are absolutely right. Don't know where I got that 14,000
from...
Ed Campbell
If I were to convert String to Cstring would I have to change any code?
Thanks - Ed Campbell
"Arnor Baldvinsson" <ar...@icetips.com> wrote in message
news:3d73d2b4...@news.softvelocity.com...
Doug
Doug
"Bo Schmitz" <Bsch...@centurytel.net> wrote in message
news:3d73ab4a$1...@news.softvelocity.com...
Lesley Dean
I would think that one reason to use a CSTRING over a STRING would be that
in 32bit, STRING is limited to 4mb, but CSTRING is unlimited. Also, CSTRING
is generally more compatible with other languages, and other database
backends. You can read more of the differences in the docs.
Hope this helps.
--
-----------------------------
Lesley Dean
CapeSoft
Web: www.capesoft.com
"Ed Campbell" <e...@hgea.org> wrote in message
news:3d73...@news.softvelocity.com...
Randy Goodhew
of
neither a STRING nor CSTRING of greater than 4194305 bytes in size.
--
Randy Goodhew
---[ eQ ]---
Kurt Pawlikowski
There is a possibility that some structures or passed parameters native
to Clarion may not like CSTRINGs. I.e., a file name definition (Prop:Name)
may not care for them since properties are strings.
Regards,
kurtt
Kurt Pawlikowski
The Pinrod Corporation
ku...@pinrod.com
(773) 284-9500
http://pinrod.com