I create a series of tables in memory to hold deleted records.  In
developing a generic database module, I load the DDL to create the
tables from a folder containing DDL/SQL files for each table with
the following routine:

  AppPath := ExtractFilePath(Application.exename) + 'AppTables\';
  Found := FindFirst(AppPath + cDDD_MASK, 0, SearchRec);
  while Found = 0 do begin
    try
      with DeleteQuery do begin
        Active := False;
        SQL.Clear;
        SQL.LoadFromFile(AppPath + SearchRec.Name);
        ExecSQL;
      end;
    except
      on E: EEDBError do begin
        raise EOleException.Create('Del Table Error: ' + E.Message,
              EDataBaseOpenError, '', '', 0);
      end;
    end;
    Found := FindNext(SearchRec);
  end;

It works fine as long as the contents of each file contains the same
number of lines or greater.  But when I load a file with fewer lines
than the previous one I get the following:

ElevateDB Error #700 An error was found in the statement at line 21 and
column 1 (Expected end of expression but instead found MAX).  But the
file I loaded when the error occurred only has 19 lines.  When I load
the first file and look at the SQL property, the Count is 23 and SQL[22]
contains only a string of unprintable characters.  (SQL[21] contains the
last line of text.)  When I load the second file and look at the SQL
property the Count is 18, but I can look at text in SQL[19].  (I should
get an error trying to reference a line beyond the end of the SQL.Count
property.)  It's as though the SQL.Clear is not actually wiping out all
text in the object.

(Delphi Turbo, ElevateDB 1.02 - Unicode version)  Any ideas?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon


What happens if you load into a regular TStringList and .Assign it to SQL?

Roy Lambert

Roy Lambert wrote:
>
> What happens if you load into a regular TStringList and .Assign it to SQL?

Interesting.  Because I'm using the Unicode version, if I run the
SQL.LoadFromFile() function, the file needs to be in Unicode format (or
else it does not load properly) and the problem occurs.  If I load the
file into a TStringList and then .Assign it to SQL, the file needs to be
in ANSI format and everything works fine.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< Interesting.  Because I'm using the Unicode version, if I run the
SQL.LoadFromFile() function, the file needs to be in Unicode format (or else
it does not load properly) and the problem occurs.  If I load the file into
a TStringList and then .Assign it to SQL, the file needs to be in ANSI
format and everything works fine. >>

That is correct.  The Unicode version uses the Delphi TWideStrings object to
manage the SQL property.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> That is correct.  The Unicode version uses the Delphi TWideStrings object to
> manage the SQL property.

But when I use the SQL.LoadFromFile function

But when I use the SQL.LoadFromFile function and load a unicode file,
that's when the SQL lines get messed up.  Try creating a table with 6
fields and then create a table with 3 fields.  (See my code from the
original post.)

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< But when I use the SQL.LoadFromFile function and load a unicode file,
that's when the SQL lines get messed up.  Try creating a table with 6 fields
and then create a table with 3 fields.  (See my code from the original
post.) >>

Sorry, I mis-read your original post.  Unfortunately, we use the standard
TWideStrings, and it appears to be a bug in the TWideStrings object:

http://groups.google.com/group/borland.public.delphi.database.ado/browse_thread/thread/feadb8acf78015c2/3c0d0fcaf4981d50?&hl=en#3c0d0fcaf4981d50

I can't access that particular QC report on the CodeGear site, so I don't
have any idea whether it has been fixed or not.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
>
> Sorry, I mis-read your original post.  Unfortunately, we use the standard
> TWideStrings, and it appears to be a bug in the TWideStrings object:
>
> http://groups.google.com/group/borland.public.delphi.database.ado/browse_thread/thread/feadb8acf78015c2/3c0d0fcaf4981d50?&hl=en#3c0d0fcaf4981d50
>
> I can't access that particular QC report on the CodeGear site, so I don't
> have any idea whether it has been fixed or not.

OK.  Thanks for letting me know.  I'll continue to use the workaround
until I get an update from Code Gear.

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com