David Jordan wrote:
> Tony
>
> One thing, and I may be wrong, is that MV.Net is about accessing the
> database directly. This puts Multivalue in the same bucket as other
> RDBMS in performance.
David, mv.NET is a suite of three libraries, and there's more than one way
to run a program. Specific to your comments, we can do this:
mvAccountObject.CallProg("BASIC.program.name",arg1,arg2,...)
and that will execute any BASIC subroutine on the server just like any
server-side BASIC program doing a call. This is similar to a UniObjects
UniSubroutine call.
We can also Execute a TCL command, capturing and returning data just as we
do from server-side BASIC.
This sort of code would only be used where a client-side interface is
required. Relational databases can accept command-line queries just like
MV can, and we'd really be after server-side numbers anyway. But when
people say "how fast is it", they might want to know so that they can
extract data into some remote client - it wouldn't be good to have fast
server numbers and poor data transmission numbers, or in the case of QM to
not be accessible (natively) via ODBC/OLEDB at all. Since every MV
platform has different external interfaces, I'm suggesting mv.NET as one
possible standard by which all MV platforms can participate in
client-interface testing like this.
> An area of efficiency and capability of U2 is in the Basic programs
> within U2. We need to access those from .Net as we would a stored
> procedure in SQL Server.
A stored procedure in SQL Server is defined with:
CREATE PROCEDURE [dbo].[ProcName] (params...) AS
INSERT INTO ...
And then they do this:
SqlCommand cmd = new SqlCommand("ProcName",connection);
cmd.CommandType = System.Data.CommandType.StoredProcedure;
... // set parameters
rows = cmd.ExecuteNonQuery();
We use BASIC to OPEN and WRITE files as our "stored procedures". And we
can call to BASIC subroutines using the same ADO.NET syntax that's used to
call a stored procedure in an RDBMS. That is, the mvCommand class
implements the same IDBCommand interface as the SqlCommand class. So we
can do this:
mvCommand cmd = new mvCommand("ProgName",connection);
cmd.CommandType = System.Data.CommandType.StoredProcedure;
... // set parameters
rows = cmd.ExecuteNonQuery();
Look familiar? That can be coded so that a single test doesn't even know
whether the data is coming from MV or relational - it's the exact same
code.
> If you don't use the Basic programs for the business rules in a .Net
> application one loses a lot of the advantages of U2 and creates many
> of the issues in client server architecture.
I didn't want to imply that code intended to benchmark a server would be
done on a remote client, and I fully agree that server-side benching should
be done with BASIC on the server. What I'm suggesting is that of the many
tests that would need to be run in a "real world" benchmark, like a query
from Crystal Reports or other similar product, we should run through a
common interface to get an apples/apples comparison.
T
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
