Subject | Re: [IBO] Strange TFieldTypes |
---|---|
Author | Jason Wharton |
Post date | 2001-02-21T15:57:15Z |
Indeed this is a real pain in the rump.
Let's go offline and try and resolve how we can avoid these problems, OK?
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
Let's go offline and try and resolve how we can avoid these problems, OK?
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Rohit Gupta" <rohit@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, February 21, 2001 1:13 AM
Subject: Re: [IBO] Strange TFieldTypes
>
> ----- Original Message -----
> From: "Jason Wharton" <jwharton@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Wednesday, 21 February 2001 19:00
> Subject: Re: [IBO] Strange TFieldTypes
>
>
> > My apologies for this. I have someone who is in the middle of a very
large
> > BDE to IBO conversion and I am trying to make things overall more
> flexible.
> > It really is a challenge.
> >
> > I don't understand why you are having these two problems that well. I
> wonder
> > if your packages are properly rebuilt after applying source changes?
>
>
> Thats never a problem, with Delfi's inability to keep track of file
changes
> and NTs ability to change the file size without changing its modification
> date, we regularly delete all dcus and rebuild everything. Infact I know
of
> people who have added a menu option to the IDE to delete all dcus :-)
>
> Problem # 1 - This kicked in once we had gone system wide and changed all
> primary keys for 74 odd tables from longint to int64 and made various
other
> changes. After that the emulated bug kicks in on openeing the form and
> insists on converting most fields to largeint.... no matter what you do.
> The only solution is to delete all persistent fields anf lose all
formating
> and linking info and events and to recreate them.... but then, as soon as
> there is an error, all fields again want to become largeints again. If
you
> look at that code - on error a numeric with a scale is being foeced to
> largeint.... madness. The best solution was to remove the bug.
>
> Problem # 2 - This is really a problem with Borlands stupidity. They said
> they had implemented int64, which is why we reorganised the database to
use
> them..... then we find that Variants dont support it, Borland blame
> Microsoft (amazing), TFIeld doesnt support it etc etc... Which means all
> setrange, findkey, locate etc that use an int64 field just fail.
>
> The not so obvious problems lurked in the lookup fields defined in the
> tables.
>
> The other not so obvious problem is the type integer. Anyone that has
been
> beta testing Pascal and Delphi would remember that when Borland changed
the
> meaning of integer from 2 bytes to 4 despite universal protest, they
> promised that type integer would now always reflect the widest word
> supported.... well, int64 has fallen through the cracks..... so
everything
> using integer fails.
>
> Aargh, I would cheerfully throttle the person at Borland that decided to
> implement a half-a...d solution for int64.