Read-only table error in demo program Delphi 7 TDbf 7.01

[Laurie Boshell]

The Create table demonstration program that ships with TDbf reports : "Dbf1: Cannot modify a read-only dataset." when the "Populate" button is clicked. This is after "Method1" and "method2" buttons have been clicked to create the table. This is Delphi 7, Windows XP SP3.
The same code executes correctly in Lazarus 1.6, FPC 3.0.0 Windows XP SP3 without fault.
Screen capture enclosed.
Does anyone have a solution?
Laurie

[Damir Šimunović]

Have the same problem with Delphi 10 Seattle, but with settings Croatian (Croatia).

Tried to create new table: it is created, but is ReadOnly.

But in the demo CompatibilityForm IT IS NOT read only: I can change the field CHAR and also the Memo field! I can add new record! But the codepage is wrong! If I type in Croatian national characters (ISO-88592 or Latin-2 or Windows-1250 for Eastern Europe) šđč枊ĐČĆŽ, it returns šđccžŠ?CCŽ.

ADDITIONAL INFO: demo CompatibilityForm is not read only for dBaseIV, dBase for Windows and Visual dBase, but is read only for dBase III+.

[LS Ploeger]

I checked with Delphi 10 Seattle and Delphi 5, but could not reproduce this issue. The interesting point is that you were able to create the table, but perhaps something is wrong with the code page settings on your system. Internally, TDbf performs the following check:

function TDbf.GetCanModify: Boolean; {override;}
begin
  if FReadOnly or (csDesigning in ComponentState) or (not Active) then
    Result := false
  else
    Result := FTranslationMode > tmNoneAvailable;
end;

The value of FTranslationMode depends on the code page that is retrieved from your system. Can you check e.g. regional settings to see if something is ill-configured?

[Laurie Boshell]

I have tried numerous changes to the Regional settings. I am located in Sydney Australia.
Using the correct settings of:

Standards and Formats = English(Australia)

Location = Australia

causes the "Cannot modify a read-only Dataset" error. Win XP SP3, D7, TDbf 7.01
The version of TDBF shipped with Lazarus 1.6 FPC 3.0.0 works perfectly.

Note that if I lie and use:

Standards and Formats = English(United States)

Location = Australia

then it works, but dates are mm/dd/yy not dd/mm/yy for this side of the Pacific!

Before attacking the source code, is this a bug? Please try these settings on your machine.
Is there something that I am missing? Is there a reason why the Lazarus/FPC version works correctly? Images of settings that work and do not work are attached.

[Damir Šimunović]

Does somebody solve the problem? As I understand, the problem arises only for Win1250 codepage, and when I comment following part of the source in dbf.pas, TDbf.InternalOpen, it seems to work corectly:
// 11.09.2007 Ĺńäč 0, íŕďđčěĺđ DBaseIII, áóäĺě ń÷čňŕňü čç DbfGlobals
( if FDbfFile.LanguageID=0 then begin
FDbfFile.UseCodePage := DbfGlobals.DefaultCreateCodePage; // GETACPOEM;
FDbfFile.FileLangId := DbfGlobals.DefaultCreateLangId; // DbfLangId_RUS_866
end; )
// Đĺŕëüíűé locale čç çŕăîëîâęŕ ôŕéëŕ
I don't know why, but FDbfFile.LanguageID is 0, and FDbdFile.UseCodePage before this part is executed is 1250, but after this it becomes 0.

But I didn't test it hard. Any idea?

Why is this part even included? I can't read the comment before and after this part.

[Manuel Parra]

Hello,

I've been trabajadon with this component is pretty good, but has some flaws in the latest version not yet repaired.

Creating tables is unstable and little comfiable
.mdx Management indexed files, it does not work very well and you have to constantly make a pack to the table.

Those are the details that I found, superbien else works ...
To create DBF table in DELPHI XE I advise you to use the ADO tool.
TDbf that comes with the typical message ReadOnly Dataset, when you go to record registration

Here dejos the steps I found on the net and was very useful to solve the problem of creation ..... good luck

procedure TfrmADODBF.Button1Click(Sender: TObject);
var sDBPath, sTableName, sSQL : String;
begin
sDBPath := 'D:\Tmp';
sTableName := FormatDateTime('DDMMMYYYY', Date) + '.dbf';
//07Jun2005.dbf
Screen.Cursor := crHourGlass;
with ConnDBF do
begin
Connected := False;
LoginPrompt := False;
ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' +
sDBPath + ';Extended Properties=DBASE IV';
Connected := True;
end;
Screen.Cursor := crDefault;
Screen.Cursor := crHourGlass;
sSQL := 'CREATE TABLE ' + sTableName + ' (EMPNUM CHARACTER(5), ENAME
CHARACTER(25)) ';
ConnDBF.Execute(sSql);
Screen.Cursor := crDefault;

ConnDBF.Connected := False;
end;

procedure TfrmADODBF.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action := caFree;
end;

[LS Ploeger]

By comparing v7.0.1 with v6.9.1 I found that this code change in dbf.pas is most likely responsible for the tables showing up as read-only for e.g. the Australian locale:

// 11.09.2007 Åñäè 0, íàïðèìåð DBaseIII, áóäåì ñ÷èòàòü èç DbfGlobals
if FDbfFile.LanguageID=0 then  begin
  FDbfFile.UseCodePage := DbfGlobals.DefaultCreateCodePage; // GETACPOEM;
  FDbfFile.FileLangId := DbfGlobals.DefaultCreateLangId;     // DbfLangId_RUS_866
end;

I don't know why this was added, it was done with r297 (https://sourceforge.net/p/tdbf/code/297/#diff-1). The real issue here is that the locale is not recognized properly. A possible fix would be to revert to DbfLangId_ENU_850 in TDbfGlobals.SetDefaultCreateCodePage when no matching code page was found for the current code page/locale.