[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for testing experimental patch

I think we are talking past eachother here.

Here is the situation:

In ap there is a primary key called "id" which is guaranteed unique within the ap table.  It is generated from the 'id' sequence.  The ar table is similar.
In gl there is a primary key called 'id' which is guraranteed unique within the gl table.  It is generated from the 'id' sequence.
In the acc_trans there is a pseudo foreign key called trans_id which refers to any of (among other things) the id fields from ar, ap, and gl.

So if the id sequence gets out of whack, when you enter, say, a GL entry, it will prevent you from assigning an id to the entry if it exists in the gl table but not if it exists in the ar or ap tables.  In the latter case the pseudo foreign key in acc_trans becomes ambigous.

Does this make more sense now?

Long run, these tables are going to be radically altered to avoid this problem in a more structural way, but for the moment, this seems like the easiest way to stabilize the situation and prevent more corrupted data.

Best Wishes,
Chris Travers

On 9/14/06, David Tangye <..hidden..> wrote:
On Wed, 2006-09-13 at 11:49 -0700, Chris Travers wrote:
> You misunderstand.  id is unique within ap.  It is not unique between
> ap and gl, for example.
I would have a table for each group of tables that has a unique id. Each
table suggests an entity that has not yet been

>  I don't think that distinct adds anything.
It removes duplicates if there are any in the source table, thus is a
small data-scrubber. The default 'any' does not.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Ledger-smb-devel mailing list