Subject Re: VARCHAR
From Mervyn Bick <invalid@invalid.invald>
Date Sat, 4 May 2019 21:05:08 +0200
Newsgroups dbase.getting-started

On 2019-05-03 8:28 PM, Mustansir A Ghor wrote:
> Dear All
> 1. What  option should we go for if we were to store variable length text in a table that can be either brief description or Logical text like NEGATIVE/POSITIVE or non math NUMERIC or an image file name or PDF  file name.

.dbf tables do not support a VARCHAR field type.  The only options are a
character field if the maximum length of any value to be stored is less
than 254 characters or a memo field.  With a character field the field
width must be specified.  With a memofield the BDE provides whatever
space is needed.

> 2. What difference will it make if we store an image file in a binary field or we store the image file name in character field and obtain its image via image control.

A binary field is stored in a .dbt table with the same name as the .dbf
file exactly like a memofield.  Personally I prefer to store the image
file name in a character field and keep all images in a separate folder.

The only time I would consider saving images in a .dbt file is for, say,
something like identity photos and specimen signatures where security is
important.  Individual files in a folder can easily be replaced outside
of dBASE.  Replacing images in a .dbt file requires access to dBASE code.

> 3. It is seen that A character field can be edited with Memo editior, where ENTER behaves correctly. For the same field , an ENTRYFIELD stores simply the text whereas Memo editor rearranges this text with inclusion of ENTER key placement. However other formating options do not work. Can we use Character field to store formating codes and other control codes as we do in memo field.

It's not a Memo editor.  It's an editor control.  It can be data linked
to either a character field or a memofield.

One can store any characters, including chr(13), chr(10) and chr(9) in a
character field.  In a program you could do something like

  oRef.fields['whatever'].value = 'This is line
1.'+chr(13)+chr(10)+'This is line 2.'

In an entryfield it would display as

This is line 1. This is line 2.

In an editor control it would display as

This is line 1.
This is line 2.

You can't enter chr(13)+chr(10) in an entryfield.  You can use the Enter
key in an editor control to insert the chr(13)+chr(10) to give a new line.

If you want enter and display multi-line text use an editor control
instead of an entryfield.

> 4. For a table in db4, the memo file kept records of only those records whose memo field content were not empty. Is this same  for db7 table

The contents of a memo field is kept in a .dbt file with a name
corresponding to the .dbf file.  Space in the .dbt file is allocated in
blocks according to a setting in BDEAdministrator.  The block size is
typically 512 or 1024 bytes but you can use whatever you like.

Blocks are only allocated in the .dbt file when data is entered in a
record's memofield.  If the memo for record 100 is entered before the
memo for record 1 then the data for record 100 will precede the data for
record 1 in the .dbt file. dBASE stores the starting block number for a
record's memo in the .dbf file so it doesn't really matter where the
data is kept in the .dbt file.  dBASE will find the memo when you select
the record.

With level 4 tables changing 1 character in a memofield caused dBASE to
abandon the blocks for the exiting entry in the .dbt file and allocate a
new block (or blocks depending on the length of the memo) at the end of
the .dbt file.  This could result in the .dbt file growing enormously
especially if regular edits are made.  A periodic PACK was needed to
keep the .dbt file size reasonable.

My understanding is that with level 7 tables blocks are only abandoned
and the memo is only moved to the end of the .dbt file if the original
allocated space can't accommodate the changes.  The .dbt file can still
grow but not as quickly as before.  As with level 4 tables, PACK (or
packTable() in OODML) will remove any abandoned blocks.