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. Mervyn.