Re: Call for testing experimental patch

["Chris Travers" <..hidden..>]

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
discovered/recognised/defined.

>  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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel