Board index » delphi » compiles and runs on my machine, does not compile and run on my bosses

compiles and runs on my machine, does not compile and run on my bosses

(environment: Delphi 3, paradox 7, BDE 4.51, Windows 95 and 98, stand
alone app)

I am stumped and I need help.

We have some database code compiled on my machine or Linda's machine
runs on my machine on everyone else's machines just fine. This same code
compiled on my bosses machine or a couple of other people's machines
causes an error, when run on everyone's machine.

The error is on a line where I POST a record which was just APPENDed.
The error refers to a primary key, autoincrement field called
WeightRateID.

     The error is "Field WeightRateID must have a value".

This makes no sense but it makes perfect sense. Of course it needs a
value. For gosh sakes it is an autoincrement field, if I POST then it
gets a value, thank you very much. In fact if you manually go to the
table in question using Database Desktop and append a record (F9), put
some data into a field then hit F9 to POSt it works just fine in ALL
cases. Are appearances deceiving? Does autoincrement work when we
compile code on my or Linda's machines but not on other people's
machines?

I have tried shotgunning this but to no avail. My problem is in
understanding WHAT is wrong. I tried checking everyone's compile Options
. . . all the same. I made sure we all have the same componenets on the
IDE . . . fine there. I checked the Environment options . . . no effect
after syncing them up. I checked the BDE and belive they are all the
same. I still suspect the BDE or some related option or setting. <sigh>

I am lost. I have no idea what else to check.

thanks in advance

Jeannine Menger
PC Synergy
760-931-0350

 

Re:compiles and runs on my machine, does not compile and run on my bosses


Hi Jeannine,
this is just a shot, but did you compare the data?
Look whether "Required field" is not checked in
the autoincrement field Validity checks options
in Database Desktop. It should *NOT* be checked.
--
Roman
(please remove 'stopspam' in header)
mail: i...@rksolution.cz
URL: www.rksolution.cz

Re:compiles and runs on my machine, does not compile and run on my bosses


The best I can do is a couple of wild guesses. First, make sure the Required
valcheck for the autoinc field is not set. Second, what is different about
the machines that produce an exe that works and those that do not?
Different update levels of Delphi? Different O/S?

Bill

--

Bill Todd - TeamB
(TeamB cannot respond to email questions. To contact me
 for any other reason remove nospam from my address.)

Re:compiles and runs on my machine, does not compile and run on my bosses


Quote
Bill Todd wrote:

> The best I can do is a couple of wild guesses. First, make sure the Required
> valcheck for the autoinc field is not set.

Both you and Roman suggested this. I will check. This seems plausible.

Quote
>Second, what is different about
> the machines that produce an exe that works and those that do not?
> Different update levels of Delphi?

No, all are 3.0

Quote
>Different O/S?

3 of machines are win95, two work one does not. The other two are win98

Re:compiles and runs on my machine, does not compile and run on my bosses


Quote
Jeannine Menger wrote:

> (environment: Delphi 3, paradox 7, BDE 4.51, Windows 95 and 98, stand
> alone app)

> I am stumped and I need help.

> We have some database code compiled on my machine or Linda's machine
> runs on my machine on everyone else's machines just fine. This same code
> compiled on my bosses machine or a couple of other people's machines
> causes an error, when run on everyone's machine.

> The error is on a line where I POST a record which was just APPENDed.
> The error refers to a primary key, autoincrement field called
> WeightRateID.

>      The error is "Field WeightRateID must have a value".

> This makes no sense but it makes perfect sense. Of course it needs a
> value. For gosh sakes it is an autoincrement field, if I POST then it
> gets a value, thank you very much. In fact if you manually go to the
> table in question using Database Desktop and append a record (F9), put
> some data into a field then hit F9 to POSt it works just fine in ALL
> cases. Are appearances deceiving? Does autoincrement work when we
> compile code on my or Linda's machines but not on other people's
> machines?

> I have tried shotgunning this but to no avail. My problem is in
> understanding WHAT is wrong. I tried checking everyone's compile Options
> . . . all the same. I made sure we all have the same componenets on the
> IDE . . . fine there. I checked the Environment options . . . no effect
> after syncing them up. I checked the BDE and belive they are all the
> same. I still suspect the BDE or some related option or setting. <sigh>

> I am lost. I have no idea what else to check.

Are each of the machines using the same BDE configuration-file?  (For
example, a common copy placed on the network?)  Are they using exactly
the same (shared) database or a local copy?

What exactly happens if you copy the config file from a known-working
machine to one that does not work?  The database?

Re:compiles and runs on my machine, does not compile and run on my bosses


Amazing.  I cannot imagine what would causes differences in the compiled EXE
other than differences in the Delphi versions or the versions of add-ins or
custom components.

Bill

--

Bill Todd - TeamB
(TeamB cannot respond to email questions. To contact me
 for any other reason remove nospam from my address.)

Re:compiles and runs on my machine, does not compile and run on my bosses


Hi Jeannine,

It's not an area I know much about but, on the machine that doesn't
work, have any entries been made in the Dictionary section within
Database Explorer that could affect the program. The reason I ask this
is that I believe that entries made here can interact with the program
at design/compilation time via the Constraints property of TTable.

Cheers,
Carl

Quote
Jeannine Menger wrote:

> Bill Todd wrote:

> > The best I can do is a couple of wild guesses. First, make sure the Required
> > valcheck for the autoinc field is not set.
> Both you and Roman suggested this. I will check. This seems plausible.

> >Second, what is different about
> > the machines that produce an exe that works and those that do not?
> > Different update levels of Delphi?
> No, all are 3.0

> >Different O/S?
> 3 of machines are win95, two work one does not. The other two are win98

Re:compiles and runs on my machine, does not compile and run on my bosses


OK I now have the answer. It was suggested in a couple of early replies
that I make sure that my autoincrement, primary key fields not have the
REQUIRED check box checked. I tried this and lo and behold THIS was the
problem. I know this because I can re-create the problem quite easilly
by re-instating the required setting. I also then had the same problem
with another table down stream in my code, same issue, same solution.
Fact is I went in and deleted all the .VAL files and changed the
required = True in the table scripts so we do not re-create the same
problem later.

I would call this one of the "Paradox commandments" . . . "thou shalt
not make thine autoincrement, primary keys required elst thow shalt
suffer intermittent compilation from machine to machine. Amen."

If anything I would like to let the folks at Inprise know of this
behaviour so maybe in future versions of Paradox they could not allow
the required check box to be accessed if you are on the primary key and
it is an autoincrement type field. This surely would save a lot of
people the same headache. It is standard design for an MS ACCESS
database table to have a primary key, autoincrement field with the
REQUIRED setting true. In fact to me it makes intuitive sense. Maybe
this is why they call it a Paradox????

Now why Linda and I could compile and run on any machine while others
could not . . . only the people who wrote the innerds of Paradox could
answer. If they could identify WHAT went wrong then find out WHY perhaps
a solution might be forthcoming.

In any event, we are still on track. Once again this newsgroup has saved
us months of problems and work-arounds. Thanks all.

Jeannine Menger
PC Synergy
760-931-0350 x119

Other Threads