The session object exposed to VBScript has two methods, GetObject and NewObject, but I'm not really sure on how they operate specifically because a few tests seemed they yielded the same results, both methods would give me a new object handle each time it was called in a repetitive script.  Even though you would expect GetObject to only get a new object handle if the class you are passing it does not already exist.  It has been a while since I've done this test so I'm not certain that it is still behaving that way.

ProvideX uses the New function which you would normally just pass in the class that you want to create, this is what I believe the ProvideX.Script object's NewObject method is doing.  However, most of Sage 100 classes require a SY_Session object to be associated with the created class, this appears to be done automatically when using SY_Session's GetObject.  Using SY_Session's methods also have the benefit of setting and being able to check its LastErrorMsg in the event GetObject fails, whereas using the oScript.Evaluate or oScript.Execute to create a new object by passing it ProvideX code to use the New function does not seem to do this.  Using ProvideX.Script object's NewObject appears to have the same result as the New function, however, when using ProvideX.Script object's NewObject for a class like AR_Customer_Svc, you need to pass a session object handle as the second argument as well.

Thanks David for the reply. I have never used GetObject and only NewObject to create BOI references to objects. Here is the ProvideX COM/OLE automation typelib info from the ScriptBasic COM extension module display typelib info function.The NewObject takes up to 19 arguments of a variant type.

Interface: IScript
ProgID: ProvideX.Script.1
CLSID: {60503AB4-2D27-11D6-B249-00C04F50D575}
Version: 1.0
Get Instance() As String
Sub Init(Path As String, [Param As Variant])
Get State() As ScriptState
Sub Execute(CmdLine As String)
Function Evaluate(Expression As String) As Variant
Sub Run(ProgramName As String)
Get Parameter(Name As String) As Variant
Let Parameter(Name As String, Variant)
Function NewObject(ClassName As String, [Param1 As Variant], [Param2 As Variant], [Param3 As Variant], [Param4 As Variant], [Param5 As Variant], [Param6 As Variant], [Param7 As Variant], [Param8 As Variant], [Param9 As Variant], [Param10 As Variant], [Param11 As Variant], [Param12 As Variant], [Param13 As Variant], [Param14 As Variant], [Param15 As Variant], [Param16 As Variant], [Param17 As Variant], [Param18 As Variant], [Param19 As Variant]) As Object
Sub Reset()
Function AddNamedObject(Name As String, Obj As Object) As Boolean
Function DeleteNamedObject(Name As String) As Boolean
Get TraceOn() As Boolean
Let TraceOn(Boolean)
Get Trace() As Boolean
Let Trace(Boolean)
Sub SetCommandLine(CommandLine As String)

My previous example works fine. I had to enhance the extension module to deal with the Sage 100 inheritance framework. I'm looking for an examples that may inherit more than SY_Session or pass value based arguments as well.

Typelib info on objects created with the ProvideX NewObject are useless. 100 COM objects are emulations and don't follow COM standards. You're pretty much blind other than what the docs provide.

Note: The TRACE feature only works with a M/D key.

It really depends on the class that you are wanting to create.

For example, a class like SO_SalesOrder_UI, like most tasks' UI class, can have a key passed as an argument to its Process method and the UI object will attempt to load the record when it is displayed to the user.

Whereas the CM_UDT_Svc and CM_UDTMaint_Bus classes require the UDT name to open to be passed as an argument.  If using the session object to create the object, the class is the first argument and the UDT name is the second argument.  If using the ProvideX.Script object to create the object, the class is the first argument, the session object is the second argument and the UDT name is the third argument.

As for passing additional arguments or values, you can try passing values as additional arguments and the use the created object's GetValue method to check the values of the variables Arg_1$ through Arg_20$ but I'm not sure this is implemented the same for all of Sage 100's classes when they are created vs the UI object's Process method.

I'll take a peek at the _UI object creation for an example to play with. I was able to get the Customer ALE lookup dialog to display via external BOI scripting.

I'm about to release an updated ScriptBasic Win32 Core Inno install to allow other Sage consultants an easy way to do external BOI scripting and ODBC access. (C interface not ADO) I wanted to validate that NewObject can handle the mix of 100 variations before the final build.

ScriptBasic is open source, FREE with a MIT Common license, (no restrictions with its use)

David Speck and Kevin M,

Would guys be willing to give ScriptBasic a spin around the block before I do the official release of the update?

If so, please send me an e-mail to [email protected] and I'll e-mail you the install. The included README, User Guide and examples should get you rolling.,

Here is the ScriptBasic IDE / Debugger.

C:\ScriptBasic\examples>sbc com_100.sb
Customer:  ABF  American Business Futures  Milwaukee  WI  (414) 555-4787

C:\ScriptBasic\examples>

ScriptBasic programs are just text files. I use UltraEdit for most of my programming and the IDE for debugging if needed. ScriptBasic tokenizes the scripts in a binary format at runtime for speed. ScriptBasic is written in ANSI C, cross platform and runs on everything.

I'm pretty busy with active projects at the moment and not sure when I'll get time to tinker with something of this scope.

It looks nice enough to tinker with but I'm still unsure of how well it would be received by clients when attempting to implement a project founded on it as it would be another third party dependency and for strict environments, it may be difficult to implement.

ScriptBasic is used commercially and is solid as a rock with over 18 years of being production stable. My proposal is using ScriptBasic for external BOI scripting and ODBC access. I really think it would be worth your time taking a quick look. (run examples in a console and IDE)

If anyone else with BOI and traditional BASIC skills would like a copy to play with let me know.

Maybe if you would elaborate here on why it is easier than VBScript (and the plethora of editors for it) and what the "C" interface has over ADO would get you more attention. You are asking busy people to learn a new language when we already have to know VBScript for internal scripting, Crystal's scripting & Basic syntax language and some ProvideX. I assume there is a compile option so that all users don't have to install ScriptBasic. That would be a non-starter for me.

ScriptBasic is much easier to use and understand than emulation BASIC (ProvideX) and only a 800KB footprint for the interpreter. Your programs can run in a console with STDIO redirection or as a true Windows program. You can also embed your scripts in C using ScriptBasic as a DLL. Programs can be saved as a standalone .EXE and distributed that way without installing ScriptBasic on the client's PC.

The ScriptBasic ODBC extension module is a C interface to the ODBC Windows API. Lightning fast without the bloat ADO brings with it,

' Sage 100 Customers - ABC Demo (ProvideX ODBC Driver)

IMPORT odbc.sbi

dbh = odbc::RealConnect("SOTAMAS90","","")
odbc::Query(dbh,"SELECT * FROM AR_Customer")

WHILE odbc::FetchHash(dbh, column)
  PRINT column{"CustomerNo"}," - ",column{"CustomerName"}," - ",column{"TelephoneNo"},"\n"
WEND

odbc::Close(dbh)

I'm willing to bet after an hour of playing with ScriptBasic you will put VBScript on the shelf for external scripting projects. 

I don't do external BOI scripting, so I don't see this is something I'd ever use.