Subject | [IBO] Re: BDE to IBO Conversion Issue Resolved |
---|---|
Author | danialwidner |
Post date | 2002-06-08T20:17:29Z |
I would love to. However, the trimmed down sample works perfectly.
Using an empty (created from ddl) database also works perfectly with
the larger app having the problem.
The demo code that has the "problem" in the larger app is simple.
procedure TfrmETS.SaveMessage(LogID : Integer; Source,Mesg : String);
begin
try
qryMessageID.Close;
qryMessageID.Open;
tblMessage.Append;
tblMessageMessage_ID.Value := qryMessageIDMessageID.Value;
tblMessageLog_ID.Value := LogID;
tblMessageProcess_Date.Value := Date;
tblMessageMessage_Source.Value := Source;
tblMessageMesg.Value := Mesg;
tblMessageStatus.Value := 'VALID';
// the missing "required" fields are:
// Input_date default now
// Input_By default user
// modify_date default now
// modify_by default user
tblMessage.Post;
except
tblMessage.Cancel;
Beep;
MessageDlg('Can''t save message "' + Mesg + '" from "' +
Source + '".',mtWarning,[mbOk],0);
end;
end;
The DDL:
/* Domain definitions */
CREATE DOMAIN "DMASDATE" AS DATE;
CREATE DOMAIN "DMDATE" AS DATE NOT NULL;
CREATE DOMAIN "DMINPUTBY" AS VARCHAR(20)
DEFAULT USER NOT NULL;
CREATE DOMAIN "DMINPUTDATE" AS TIMESTAMP
DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN "DMINTEGERID" AS INTEGER NOT NULL;
CREATE DOMAIN "DMMODIFYBY" AS VARCHAR(20)
DEFAULT USER NOT NULL;
CREATE DOMAIN "DMMODIFYDATE" AS TIMESTAMP
DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN "DMVOID" AS VARCHAR(10)
CHECK (VALUE IN
('VALID','VOID','CHECKING','PENDING','OTHER')) NOT NULL;
/* Table: MESSAGE_LOG, Owner: SYSDBA */
CREATE TABLE "MESSAGE_LOG"
(
"MESSAGE_ID" "DMINTEGERID",
"LOG_ID" "DMINTEGERID",
"PROCESS_DATE" "DMDATE",
"MESSAGE_SOURCE" VARCHAR(60) DEFAULT NULL,
"MESG" VARCHAR(500) DEFAULT NULL,
"STATUS" "DMVOID",
"INPUT_DATE" "DMINPUTDATE",
"INPUT_BY" "DMINPUTBY",
"MODIFY_DATE" "DMMODIFYDATE",
"MODIFY_BY" "DMMODIFYBY",
"CLIENT_ID" VARCHAR(10) DEFAULT NULL,
"AGENCY_ID" VARCHAR(10) DEFAULT NULL,
"TAX_TYPEID" VARCHAR(10) DEFAULT NULL,
"FORM_ID" VARCHAR(10) DEFAULT NULL,
"FREQUENCY_ID" VARCHAR(10) DEFAULT NULL,
"PAYEE_ID" VARCHAR(10) DEFAULT NULL,
"CHECK_DATE" "DMASDATE" DEFAULT NULL,
"DUE_DATE" "DMASDATE" DEFAULT NULL,
"REFERENCE_ID" INTEGER DEFAULT NULL,
PRIMARY KEY ("MESSAGE_ID")
);
If I cut out the rest of the main form containing this code and just
leave it ( and the open / close of the database and table) and a
button to feed it, it works fine as well.
So the problem will have to be fixed in the environment of the error.
I have XP Pro on a dsl line at home. So a link in will be avaiable
from another XP machine if you want to test for yourself and play /
get to the bottom of it. Otherwise we are forced to change 543 table
appends to parameterized insert queries in 77 files. (the better
choice in the long run but the app can't be out of service that
long).
Dan
Using an empty (created from ddl) database also works perfectly with
the larger app having the problem.
The demo code that has the "problem" in the larger app is simple.
procedure TfrmETS.SaveMessage(LogID : Integer; Source,Mesg : String);
begin
try
qryMessageID.Close;
qryMessageID.Open;
tblMessage.Append;
tblMessageMessage_ID.Value := qryMessageIDMessageID.Value;
tblMessageLog_ID.Value := LogID;
tblMessageProcess_Date.Value := Date;
tblMessageMessage_Source.Value := Source;
tblMessageMesg.Value := Mesg;
tblMessageStatus.Value := 'VALID';
// the missing "required" fields are:
// Input_date default now
// Input_By default user
// modify_date default now
// modify_by default user
tblMessage.Post;
except
tblMessage.Cancel;
Beep;
MessageDlg('Can''t save message "' + Mesg + '" from "' +
Source + '".',mtWarning,[mbOk],0);
end;
end;
The DDL:
/* Domain definitions */
CREATE DOMAIN "DMASDATE" AS DATE;
CREATE DOMAIN "DMDATE" AS DATE NOT NULL;
CREATE DOMAIN "DMINPUTBY" AS VARCHAR(20)
DEFAULT USER NOT NULL;
CREATE DOMAIN "DMINPUTDATE" AS TIMESTAMP
DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN "DMINTEGERID" AS INTEGER NOT NULL;
CREATE DOMAIN "DMMODIFYBY" AS VARCHAR(20)
DEFAULT USER NOT NULL;
CREATE DOMAIN "DMMODIFYDATE" AS TIMESTAMP
DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN "DMVOID" AS VARCHAR(10)
CHECK (VALUE IN
('VALID','VOID','CHECKING','PENDING','OTHER')) NOT NULL;
/* Table: MESSAGE_LOG, Owner: SYSDBA */
CREATE TABLE "MESSAGE_LOG"
(
"MESSAGE_ID" "DMINTEGERID",
"LOG_ID" "DMINTEGERID",
"PROCESS_DATE" "DMDATE",
"MESSAGE_SOURCE" VARCHAR(60) DEFAULT NULL,
"MESG" VARCHAR(500) DEFAULT NULL,
"STATUS" "DMVOID",
"INPUT_DATE" "DMINPUTDATE",
"INPUT_BY" "DMINPUTBY",
"MODIFY_DATE" "DMMODIFYDATE",
"MODIFY_BY" "DMMODIFYBY",
"CLIENT_ID" VARCHAR(10) DEFAULT NULL,
"AGENCY_ID" VARCHAR(10) DEFAULT NULL,
"TAX_TYPEID" VARCHAR(10) DEFAULT NULL,
"FORM_ID" VARCHAR(10) DEFAULT NULL,
"FREQUENCY_ID" VARCHAR(10) DEFAULT NULL,
"PAYEE_ID" VARCHAR(10) DEFAULT NULL,
"CHECK_DATE" "DMASDATE" DEFAULT NULL,
"DUE_DATE" "DMASDATE" DEFAULT NULL,
"REFERENCE_ID" INTEGER DEFAULT NULL,
PRIMARY KEY ("MESSAGE_ID")
);
If I cut out the rest of the main form containing this code and just
leave it ( and the open / close of the database and table) and a
button to feed it, it works fine as well.
So the problem will have to be fixed in the environment of the error.
I have XP Pro on a dsl line at home. So a link in will be avaiable
from another XP machine if you want to test for yourself and play /
get to the bottom of it. Otherwise we are forced to change 543 table
appends to parameterized insert queries in 77 files. (the better
choice in the long run but the app can't be out of service that
long).
Dan
--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> Will you please send me a sample to look at?
> I'm determined to get this right.
>
> Thanks,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "danialwidner" <dwidner@a...>
> To: <IBObjects@y...>
> Sent: Friday, June 07, 2002 6:41 AM
> Subject: [IBO] Re: BDE to IBO Conversion Issue Resolved
>
>
> Not quite.
>
> We upgraded to the HD version with your changes. It still will not
> skip the missing fields on the append. We removed the
> GetServerDefaults := True to try your new code and it still
crashes
> for each of the missing fields. We immediately put it back so we
> could continue testing and working until you get a fix.
>
> Thanks for the effort so far. It has not gone unnoticed.
>
> Dan