TDBF with indexes causes memory errors lazarus / 16-Databases ---------------------------------------------------------------------- snarkit · 2007-07-31 13:59 I have been struggling for some days with an adaptation to Lazarus of a Delphi program that reads dBASE 4 files. I use Windows XP and Lazarus 0.9.22. I get variety of run-time errors on opening or closing a table with an index. Not all files cause the errors but once a given indexed file has provoked it the same error occurs more or less at the same point each time. All the files have mdx index files only. My program uses the method TDBF.AddIndex to add index tags, and these indexes appear to be created correctly. Subsequently, however, the files cause errors and cannot be opened. Certain tables with indexes created by dBase 5.7 also bring up these errors. It is very difficult to determine exactly what happens so I have written a test program to investigate the problem. Running that with the debugger I get a SYSGETMEM_FIXED error on opening a file that has caused a problem. The callstack shows the error is associated with an ansistring, when reading the table indexes.  The callstack is shown below. If I run the program outside the debugger, the indexes can be read a first time, and new indexes can be added, but the next time the file is opened the program crashes. This looks like one of more bugs to me, but have I perhaps caused the problem by omitting some essential setting? I have deleted the index (mdx) files where the existing indexes are based on expressions using text functions (left, substr, etc) because these are signalled as a runtime error, but I have left indexes on a single field and on an expression. I should be very grateful for help. The top of the callstack on opening a table #0 SYSGETMEM_FIXED() at :0 #1 SYSGETMEM() at :0 #2 GETMEM(, ) at :0 #3 fpc_ansistr_setlength(, ) at :0 #4 fpc_chararray_to_ansistr(, , ) at :0 #5 TINDEXFILE__READINDEXES() at :0 #6 TINDEXFILE__OPEN() at :0 #7 TDBFFILE__OPEN() at :0 #8 TDBF__INTERNALOPEN() at :0 #9 TDATASET__DOINTERNALOPEN() at :0 #10 TDATASET__SETACTIVE(, ) at :0 #11 TDATASET__OPEN() at :0 #12 TTESTBED__OPENFILEBUTTONCLICK((^TOBJECT) $10bf68, (^TTESTBED) $107e78) at tester.pas:73 ---------------------------------------------------------------------- arwen · 2007-08-02 12:09 Have you create the table with Dbf  object ? Try something like this Code: [Select] // +-------------------------------------------------------------+ // |                  Create DataBase                            | // +-------------------------------------------------------------+     with Dbf1.FieldDefs do begin          Add('NAME',ftString,80,False);          Add('POINT1',ftFloat,0,False);          Add('POINT2',ftFloat,0,False);          Add('POINT3',ftFloat,0,False);     end;     Dbf1.TableName:='Test' + '.dbf';     Dbf1.CreateTable;     Dbf1.FieldDefs.Clear; // clear field definition and then add a Index . I hope it will help you . ---------------------------------------------------------------------- snarkit · 2007-08-02 18:56 Thank you for looking at my question. I have not created a Dbf object, in fact, but I don't see how that would help. I use the TDbf objects from dbfLaz on a form. I am trying to read existing dBase tables. I can open them and look at the records using my test program, without the debugger. With the debugger there is always an error, sooner or later, on opening or closing the file.  I believe it must be a bug in Lazarus, because these files have been created and can be read in dBase. Perhaps I should spend time nailing down the problem, but at present I need to get my program working. I was hoping that I had hit on a known problem that had a known work-around. If you have any ideas I'd be grateful! ---------------------------------------------------------------------- arwen · 2007-08-03 09:01 So if you run the program outside lazarus (no debugs) it work fine ? If yes it will be a bug with gdb (the debbugger) . I have had similar problems on windows using the file and directory dialog. Using this dialogd gdb went in crash. To solve the problem I am developing  on Linux and at the end I compile the application too for Windows. On Linux there is no problem with gdb . The other solution is to debug the application with the more ancient method “print to a shell” .  :wink: I hope that it has been useful ---------------------------------------------------------------------- snarkit · 2007-09-06 12:31 :oops: Sorry for the delay in thanking you.  I was under pressure to get this one-off job done, and having got it working I dropped it.  I'll try to report the debugger error. Thanks again.