Just a little background first.....
We bought GP 6.0 back in 2001 and the implementation was directed by a consultant. At that time as a newbie developer and under direction from the consultant, I was told to write two stored procs to retrieve the next sopnumbe from SOP40300 and the next docnumbr from RM40401. Which I did, and I've used in various apps to write files for Integration Manager. Fast forward to today, we're on GP 10, getting ready for GP2010 and I need to update those external apps from VB6 to VB.NET.
I've realized two things about how those custom stored procs work:
- They don't do quite exactly the same thing as GP; we've had two people grab the same Sopnumbe on a few occasions over the past 10 years due to lack of record locking.
- They only allow for 5 numerical digits after the initial alpha character. For example, our next payment number is P74503 and the next invoice is S73990.
At this rate, we're going to hit P99999 and S99999 fairly soon. I really don't want to modify the procs when someone else has already invented the wheel.
I would like to use the stored procs built into GP's database in my .NET code and stop using the custom procs, but don't want to do it blindly or use the wrong ones. I have found eConnect documentation online, but it gives method names, which I suspect call stored procs under the covers. We don't have eConnect, and don't need it and don't plan to get it, so I can't go that route.
By process of elimination, I believe the stored procs I'm interested in are [taGetSopNumber] and [taGetPaymentNumber]. I used SSMS to script out these execute calls to see what all the parameters are; I have enough knowledge as to how to call them in .NET.
My question is: can anyone confirm that these procs retrieve values from SOP40300 and RM40401, respectively?
Thanks for any insight!
Beth
