[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Creating POs/Salesorders directly...
- Subject: Re: Creating POs/Salesorders directly...
- From: "Chris Travers" <..hidden..>
- Date: Wed, 3 Jan 2007 11:09:04 -0800
Also note that I am in favor of a stable db schema once we get to a
certain point because db-level access makes sense for certain sorts of
integration challenges (i.e. where triggers make sense). However, we
are certainly not there yet, so you should be very careful about
entering data directly into the db.
On 1/3/07, Charley Tiggs <..hidden..> wrote:
Jason Rodrigues wrote:
> On Wednesday 03 January 2007 10:36, Charley Tiggs wrote:
>> Have I left anything out? I don't have multiple warehouses so the
>> inventory table doesn't seem to come into play. Shipping/receiving is
>> not involved at this point, either.
> Genrally, you should avoid directly inserting/updating putting stuff right
> into the database.
> When you turn on the statement logging, you can get a pretty complete picture
> of what's going on, but it's not really the 'best' way right.
> We will be adding stored procedures to do many of the manipulations you
> describe, right in the db layer. Once that's togeather and working, You can
> connect directly to the database and use those SP's to manipulate the data.
> For now, I'd use the Chris' CLI tool in svn, (trunk/utils/cli) or the web
> api, where you just GET/POST urls to oe.pl. (I can get you an example later,
> don't have one handy right now)
> If you insert/update directly into the database, you'll have to carefully
> watch schema changes when you upgrade to ensure you continue to set the
> correct data. If you don't, you may find that one day you'll have a bunch of
> inconsistent data in your database. :(
> Also, in the next month or two, a REST API is coming, where you should be able
> to simply POST XML Sales order documents.
Thanks for the response. But several things are putting me on this path:
1) I'm not all that savvy with Perl, though I'm learning lots while
working with LSMB;
2) I don't always understand how the code works within LSMB but I'm
3) Because of 1 and 2, I sometimes spend up to 6 hours determining
whether it's user error (me) or a bug within LSMB.
At least, in reverting to using tools I know best (PHP, Postgres) for
the short term, I can at least program these pieces in such a way that I
can revert to using the "right way" when I finally figure out why using
the web api doesn't work for me in certain instances (I spent 4 hours
plugging at this last night without success and I still don't know if
it's a bug or user error.) or until v1.2 becomes stable.
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Ledger-smb-devel mailing list