Hi Team,
   If I do a verify on a faulty table in edbmgr, edbmgr tells me the nature of the issue and the row number.
   
   I do a verify in Delphi using the following run in a EDBScript.
{sql}
SCRIPT(IN TableName VARCHAR COLLATE ANSI_CI, IN StructureOnly BOOLEAN, OUT FAILED BOOLEAN)
BEGIN
DECLARE Stmt STATEMENT;
PREPARE Stmt FROM 'VERIFY TABLE '+QUOTEDSTR(TableName,'"')+'';
EXECUTE Stmt;
SET FAILED =  STMTRESULT(Stmt);
END
{sql}

Using the following code..
{code}
       ValidateTable.Close;
       if not ValidateTable.Prepared then ValidateTable.Prepare;
       ValidateTable.ParamByName('TableName').AsString := aDataTables[nX, 0];
       ValidateTable.ExecScript;
       //
       if ValidateTable.ParamByName('FAILED').AsBoolean then
       begin
         MessageBeep(MB_ICONERROR);
         MessageDlg('Verification of table ' + aDataTables[nX, 0] + ' failed!' + #13 + #10 + 'The table needs to be
repaired.', mtError, [mbOK], 0);
         lRepair := True;
       end;
       //
       ValidateTable.Close;
{code}

   Is it possible & if so how, to get the reason for the failed verify, a.k.a. as put out in edbmgr, programatically?
   I'd like to be a little more informed about what/where the issue is.

Regards & TIA,
Ian

Ian


Tip of the week: Remember EDBManager is "just" an ElevateDB application written in Delphi and you have the source.

To be able to compile it you'd need to install the Tim created components but often that's not necessary.

Having a dig in just searching for 'validate' and following the code through gives me a big difference between what you're doing and what Tim is doing - you use a script, he uses a TDatabaseObject.Query. That means that ultimately he's using a TEDBQuery. Looking at the TDatabaseObjects create routine Tim is using 3 of the query's events

     OnProgress:=MainForm.QueryProgress;
     OnStatusMessage:=MainForm.QueryStatusMessage;
     OnLogMessage:=MainForm.QueryLogMessage;


procedure TMainForm.QueryProgress(Sender: TObject;
                                 PercentDone: Integer;
                                 var Continue: Boolean);
begin
  ProgressBar.Position:=PercentDone;
  Application.ProcessMessages;
  Continue:=(not SQLTaskAborted);
end;

procedure TMainForm.QueryStatusMessage(Sender: TObject;
                                      const StatusMessage: String);
begin
  ShowStatus(StatusMessage);
  Application.ProcessMessages;
end;

procedure TMainForm.QueryLogMessage(Sender: TObject;
                                   const LogMessage: String);
begin
  LogMessagesMemo.Lines.Add(LogMessage);
  Application.ProcessMessages;
end;


and from the manual

TEDBDatabase.OnLogMessage Event
property OnLogMessage: TEDBLogMessageEvent
The OnLogMessage event is fired when an SQL statement is executed via the Execute method and that
statement generates log messages. Assign an event handler to the OnLogMessage event to save or
display these log messages within your application. The following SQL statements will generate log
messages:
ALTER TABLE
REPAIR TABLE
OPTIMIZE TABLE

TEDBQuery.OnStatusMessage Event
property OnStatusMessage: TEDBStatusMessageEvent
The OnStatusMessage event is fired when an SQL statement is executed via the ExecSQL or Open
methods and that statement generates status messages. Assign an event handler to the
OnStatusMessage event to display these messages in your application. All SQL statements will generate
status messages.


From all that I'd guess 1) there's a minor error in the manual and VERIFY TABLE should be in the list and 2) you need to use the OnLogMessage event and a query may be better than a script.

Roy





Roy Lambert

ps

I don't have a corrupt table to test anything out on - if you can let me have one I'll have a go



Roy Lambert

Tks Roy,
   Email sent.

Regards,
Ian

Resolved.
My thanks once again to Roy for his assistance.
Ian

Roy,

<< From all that I'd guess 1) there's a minor error in the manual and VERIFY TABLE should be in the list >>

Yep, this has been corrected.

Tim Young
Elevate Software
www.elevatesoft.com