exception raised showing too late with 1899 date

I am raising an exception inside a with statement that displays a message to the screen, however it is not displaying when it should. I trace through the code and the raise is called, however, another number of lines of code are run before the message displays. Is this normal?

Also, evaluating the exception message, it shows a FormatDateTime returns a 1999 date which is correct but when the message eventually shows it says 1899?

I am running D4.03 C/S, the exception is raised if the result of a SQL query on a SQL server table is null.

Thanks a lot, Tom.
boardtcAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
synatureConnect With a Mentor Commented:
1.  To check for no records being returned use "If EOF and BOF".  I've found this to be foolproof.

2.  To handle your kind of situation, I might use a raise exception, but I would also be sure to handle that exception within the same block of code.
 

Procedure whatever;
begin
try  // to finally
try  // to except
  ...
  open;
  if bof and eof
    then raise the exception
    else do the good processing
  ...
except
  on e:NameOfMyexception do begin
    show message or whatever
    end;
  end;
finally
  close;
  perhaps also here summarize the rsults...
  end;
end;
   
3.  Also, if the parambyname thing gives you trouble, consider simply working with the query.sql.text, which is a string that you can use stringreplace on.  That way you can much surer of what your datein value is and you can actaully do the checking there before you fire the query.

tmp := ''SELECT * FROM CALENDAR WHERE Date='+MyDateVariableFormattedForThisdialectOfSQL;
query.sql.text := tmp;
query.open;

 
0
 
simonetCommented:
Can you post some source code?
0
 
boardtcAuthor Commented:
Cheers, here is some:

with QueryIn do
begin
  {retrieve info re: date}
  Close;
  SQL.Clear;
  SQL.Add('SELECT * FROM CALENDAR WHERE Date=:Date');
  Prepare;
  ParamByName('Date').AsDate := dDateIn;
  Open;
  if NOT EOF then
  begin
    if GetIntegerParam(FieldByName('DayOfWeek')) = WEDNESDAY then
      bIsWednesday := TRUE;
    bIsLBDOM := GetBooleanParam(FieldByName('LBDOM'));
  end
  else
    raise ECalcException.Create('IndexRecord Retrieve: ' + FormatDateTime('dd-mmm-yyyy', dDateIn) + ' does not belong to the CALENDAR table.');
  Close;
end;
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
simonetCommented:

What you must do right after setting the SQL text is to tell Delphi that the datatype of the parameter "Date" is DateTime. This way it will be able to correctly mount the SQL query.

You can do that by using TParam.DataType and TParam.ParamType.

Another thing: make sure that dDateIn is a number > 0.

The fact that the Raise message box is returning 1899 is because dDateIn is probably 0, which corresponds to 30/12/1899, or 1 ( = 31/12/1899).

The exception will be raised if there are not records returned by the query, so EOF will be true.

Another thing: make sure that no other functions are altering the value of dDateIn (like in the events of the TQuery objects).

Alex



0
 
adpearceCommented:
Raising an exception does not cause a message to be displayed to the screen.  

The action that is taken when an exception occurs depends on the exception handler that traps the exception.  The default exception handler for any unhandled exceptions is to display the text of the exception in a dialog box.

By the time this exception handler has been called, your program will have 'unwound' to the top of the call stack, and the next instruction to be executed will be at the application.run level, which will probably be in response to a windows message.
0
 
boardtcAuthor Commented:
Thank you both very much for the comments. Alex, good info, I actually am setting the datatype to ftDate, it was a fucntion call that I pulled out of the above code. I will follow up to see if dDateIn is zero. Pearce, thanks for the info on exception handling, I need to lok into it more, I am especially curious when it's a good time to use exceptions over messagedlg's. Thanks again. Tom.
0
 
kretzschmarCommented:
hi all,

just a remark,

use this

ParamByName('Date').AsDateTime := dDateIn;

instead of

ParamByName('Date').AsDate := dDateIn;

meikl
0
 
boardtcAuthor Commented:
Thanks everyone for the advice. Tom.
0
 
kretzschmarCommented:
tom,
did you really got new information
about the accepted answer?
or have you just waited,
until somewhere post an answer
meikl
0
 
simonetCommented:
Why did you accept the answer?
0
 
boardtcAuthor Commented:
Meikl, I am sorry, this is always the case with this system, I got most information from AdPearce, but there doesn't seem to be a way to split the points, so I took the easy way out. Sorry about that, it was lazy. Tom.
0
 
simonetCommented:
>but there doesn't seem to be a way to
>split the points

YES, THERE IS.

You could have asked the folks in Customer Service to split the points.

Since you took the easy way out, so will I, by not answering any of your future questions.

Alex
0
 
synatureCommented:
Petty, petty.  My goodness, what is this?  Are the points that important?  
0
 
simonetCommented:
It's not a matter of points. It's a matter of attitude and respect.

Pretend every expert would do as tom and take the easy way, by giving lousy answers and making useless comments. That's very easy to do, but the experts strive to give answers to the best of their abilities. That's our part of the bargain. The user's part of the bargain is not to take the easy way, but to give credit where it's due.

Alex
0
 
boardtcAuthor Commented:
Alex, I have to apologize to you. I know I dod wrong and I ask to be given a second chance. I have emailed support and asked them to add 50 points to your account. Thanks again. Tom.
0
All Courses

From novice to tech pro — start learning today.