Representing Dynamic Arrays in VB.NET

sh,

www.PickWiki.com is Ian McGowan's mv site. I try to encourage all
Pick developers to post their code and notes there.

http://www.pickwiki.com/cgi-bin/wiki..._With_PickWiki
http://www.pickwiki.com/cgi-bin/wiki.pl?How_To_Register

rex

Rex Gozar wrote:
> sh,
>
> www.PickWiki.com is Ian McGowan's mv site. I try to encourage all
> Pick developers to post their code and notes there.
>
> http://www.pickwiki.com/cgi-bin/wiki..._With_PickWiki
> http://www.pickwiki.com/cgi-bin/wiki.pl?How_To_Register
>
> rex

OK, thanks. Right now I'm working with Mark on this stuff. Let's see
what happens.

(Late to the party, didn't send this earlier, sorry)

Sholom, please forgive, but I'm sort of surprised at the question.
..NET has a multitude of collection options for strong or weak data
types. You have the basic Collection, List, Array, ArrayList,
Hashtable, Queue, Stack, SortedList, Dictionary, and others. And you
can create a class that derives from IEnumerable, IList, ICollection,
and IDictionary.

With .NET collections you never need to redimension. That's done for
your internally, quickly, and transparently. It sounds like you're
just thinking about string[][] type object arrays.

Before you write off mv.NET, just note that you don't need to be
connected to a server to user mvItem objects, and the DataBasic class
has all the familiar functions like DCount, OConv, etc.

Good luck,
T


>Does anyone have any good ideas about the best way to represent a
>dynamic array in VB.NET?

Tony Gravagno wrote:
> (Late to the party, didn't send this earlier, sorry)
>
> Sholom, please forgive, but I'm sort of surprised at the question.
> .NET has a multitude of collection options for strong or weak data
> types. You have the basic Collection, List, Array, ArrayList,
> Hashtable, Queue, Stack, SortedList, Dictionary, and others. And you
> can create a class that derives from IEnumerable, IList, ICollection,
> and IDictionary.
>
> With .NET collections you never need to redimension. That's done for
> your internally, quickly, and transparently. It sounds like you're
> just thinking about string[][] type object arrays.
>

Thanks Tony. I definitely thought that collections were the way to go,
but when I sat down to implement it, it LOOKED like it would be complex
to set up the right 3 dimensional collection object with all the
appropriate methods. Plus, none of the books I have, give an example of
a multi-dimensioned collection. So I asked if anyone had already thought
it through, which would make life a bit easier for me.

While Mark's method doesn't use collections, It does have appeal because
it's simple and elegant. I also like it because it revolves around
strings. With collections, I'd have to construct/deconstruct the
collection to a string (which is the end result I need).

> Before you write off mv.NET, just note that you don't need to be
> connected to a server to user mvItem objects, and the DataBasic class
> has all the familiar functions like DCount, OConv, etc.

Oh no, I didn't write off mv.NET. It's just that this project involves
handheld devices, which only run the .NET Compact Framework. mv.NET
won't run on the CF.

>
> Good luck,
> T

Tony, if you have any code snippets using collections I'd love to see
it. Do you have anything on your blog? I really am only looking for the
basic dynamic array functions - Extract, Insert, Delete, Replace.
Nothing fancy. I've already written my own generic DCount, IConv, OConv,
Locate, Field and Index functions to use in VB whenever I need them.

There are many ways to skin a cat (although I've only done it on a chicken).

Sholom

Tony Gravagno wrote:
> Before you write off mv.NET, just note that you don't need to be
> connected to a server to user mvItem objects, and the DataBasic class
> has all the familiar functions like DCount, OConv, etc.
>

I'm going to second this. While the communication rate between the host
and the server is utter crap[*], the data manipulation objects are top
notch and are perfect if you want to manipulate multi-value data in a
"native" fashion. If you do any .Net programming at all, I'd recommend
buying mv.Net just for the mvItem objects.


* - In my personal experience even the C4 version of the D3 ODBC interface
(VB5) beats the snot out of the communication speed of mv.Net.

g.

Gene:

I've been using mv.NET for awhile on UniData and have found the
communication speed refreshingly fast. I use UO.NET through mv.NET and the
speed was a huge increase over our use of PDP.NET and our testing of ODBC on
D3 and OleDB on U2.

But then we're just sorry-a$$ed users, not the oracle's of CDP. :-)

Bill

"Gene" wrote in message
news:ncudnUIYqMjQOzjVnZ2dnUVZ_qfinZ2d-at-posted.conne ctcorp...
> Tony Gravagno wrote:
>> Before you write off mv.NET, just note that you don't need to be
>> connected to a server to user mvItem objects, and the DataBasic class
>> has all the familiar functions like DCount, OConv, etc.
>>
>
> I'm going to second this. While the communication rate between the host
> and the server is utter crap[*], the data manipulation objects are top
> notch and are perfect if you want to manipulate multi-value data in a
> "native" fashion. If you do any .Net programming at all, I'd recommend
> buying mv.Net just for the mvItem objects.
>
>
> * - In my personal experience even the C4 version of the D3 ODBC interface
> (VB5) beats the snot out of the communication speed of mv.Net.
>
> g.
>
>

>"Gene" wrote
>> While the communication rate between the host
>> and the server is utter crap[*], the data manipulation objects are top
>> notch...
>> * - In my personal experience even the C4 version of the D3 ODBC interface
>> (VB5) beats the snot out of the communication speed of mv.Net.

"Bill H" responded:
>I've been using mv.NET for awhile on UniData and have found the
>communication speed refreshingly fast.



Gene posted a couple notes here about issues with the D3CL and tried
mv.NET at my recommendation. We had a few rounds at it, and for some
reason performance on his system really was unacceptable so he stuck
with the D3CL. I can't blame him at all.

My conclusion is that mv.NET continues to be best connectivity tool in
our industry, but for the v3.5.1.2 release that we tried with Gene
there is something bad going on under the hood that can cause
performance to tank - and it might be D3-specific or telnet-specific
or related to some specific setting like the 8bit conversion.

In every application I've seen we'll open the connection grab some
data, then do a virtual logoff (no disconnect, eliminates pain of
logon later), and performance is pretty good. Gene is opening, then
doing several reads with calcs in between, then closing - but the
performance of the individual reads was really bad. (Still in the ms
range but adding up to many seconds per business transaction, which
simply won't do.)

I now have a v3.5.1.3 which includes changes specifically to address a
performance issue that was found in the prior release. I don't have
details of what was changed so I will just run the same tests and see
if I get better numbers before and after. I welcome an opportunity to
run these benchmarks on any system running v3.5.1.2, and then on the
same system with v3.5.1.3.

To continue discussing this product-specific issue, anyone is welcome
to register at the Nebula R&D forum where I'll post notes in the
mv.NET forum sometime in the next week.
remove.pleaseNebula-RnD.com/forum

Regards,
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide,
and provides related development and training services

Just picking up on the point regarding performance, stating at the
outset that I've not used mv.net in the past - but I believe that the
following applies.

For best performance between client and server, I have found that it
is best to keep the core business logic on the server, and interact
with it using something akin to a web service.

For example, rather than carrying out a series of transactions such
as :

1. Read Customer Record
2. Get next invoice no
3. Create Invoice Record
4. Write Customer Record
5. Update Customer Record with invoice history
6. write customer record.

Which involves 6 interactions with the server which are all "low-
level" read-writes. It is better to simply write a single transaction
which simply calls a databasic program on the server to "Update
Customer x With this sale" which does all the 6 steps in one go and
returns the success or error. Similarly, for user-interface
purposes where compiling data from multiple records for display, I've
always found it better to create a "virtual" single data structure
that is compiled on the server by a "call", which compiles the data on
the server and then returns in one go. This involves a little more
programming work, but will increase performance of the application
from the use-perspective many-fold.

Actually, I was about to start re-writing my vb.net based dynamic
array code and was also thinking about how to represent the data
structure. I'm also going to represent the dynamic array as a
string and use dotnet's extremely fast string handling code to
manipulate it. This is on the basis that most dynamic arrays are
relatively short (<100k). There will only be one exception that I'm
making, which is where the dynamic array contains information such as
a "report" which I is represented as a read-only dynamic array, with
attributes being a line of the report, and values being the columns.
These arrays can get big and I don't want to use standard dynamic
array handling to work with them which will be slow - I will convert
this immediately into a collection with each line being a fixed sized
array (of the number of columns). This will vastly speed up the
performance of generating reports (I convert the dynamic array into a
dataset for onward manipulation by standard dotnet controls).

Simon



On Aug 16, 12:09*pm, Tony Gravagno
wrote:
> >"Gene" wrote
> >> While the communication rate between the host
> >> and the server is utter crap[*], the data manipulation objects are top
> >> notch...
> >> * - In my personal experience even the C4 version of the D3 ODBC interface
> >> (VB5) beats the snot out of the communication speed of mv.Net.
>
> "Bill H" responded:
>
> >I've been using mv.NET for awhile on UniData and have found the
> >communication speed refreshingly fast.
>
> Gene posted a couple notes here about issues with the D3CL and tried
> mv.NET at my recommendation. *We had a few rounds at it, and for some
> reason performance on his system really was unacceptable so he stuck
> with the D3CL. *I can't blame him at all.
>
> My conclusion is that mv.NET continues to be best connectivity tool in
> our industry, but for the v3.5.1.2 release that we tried with Gene
> there is something bad going on under the hood that can cause
> performance to tank - and it might be D3-specific or telnet-specific
> or related to some specific setting like the 8bit conversion.
>
> In every application I've seen we'll open the connection grab some
> data, then do a virtual logoff (no disconnect, eliminates pain of
> logon later), and performance is pretty good. *Gene is opening, then
> doing several reads with calcs in between, then closing - but the
> performance of the individual reads was really bad. *(Still in the ms
> range but adding up to many seconds per business transaction, which
> simply won't do.)
>
> I now have a v3.5.1.3 which includes changes specifically to address a
> performance issue that was found in the prior release. *I don't have
> details of what was changed so I will just run the same tests and see
> if I get better numbers before and after. *I welcome an opportunity to
> run these benchmarks on any system running v3.5.1.2, and then on the
> same system with v3.5.1.3.
>
> To continue discussing this product-specific issue, anyone is welcome
> to register at the Nebula R&D forum where I'll post notes in the
> mv.NET forum sometime in the next week.
> remove.pleaseNebula-RnD.com/forum
>
> Regards,
> Tony Gravagno
> Nebula Research and Development
> TG@ remove.pleaseNebula-RnD.com
> Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide,
> and provides related development and training services

Simon:

I'd think most MV programmers would agree with your analysis. Keep it
simple and keep it on the MV server.

There are serious problems with this though. First most .NET and other
client/server programmers don't have much of a clue about this concept
because they often don't work with an application server so close to the
data (the MV server). Most of my experiences with .NET programming is that
this technology is much slower and less efficient and is much more costly to
develop, support, and maintain. I've not been able to find any .NET
programmers (or Java programmers for that matter) who follow your techniques
working with MV because this is __NOT__ the methodology they learned. The
methodology they learned is convoluted, constantly works around design flaws
of the development model, abstracted beyond belief, and time consuming to a
far greater degree than previously known in this line of work.
Consequently, it is very difficult for those of us needing help to find
decent help. Many offer, but few if any can succeed.

When I refer to mv.NET's speed, I'm talking about the connection itself.
Your overview is excellent in describing the challenges of MV in utilizing
newer abstract technologies. Your level of knowledge of both technologies
(MV & .NET) place you in a unique position to integrate both technologies,
but I'm sorry to say this capability is nowhere to be found in the general
..NET developer community.

Just IMHO of course. :-)

Bill

"Simon" wrote in message
news:40034216-5453-4938-8827-bc0f5296e1ac-at-d45g2000hsc.googlegroups.com...
Just picking up on the point regarding performance, stating at the
outset that I've not used mv.net in the past - but I believe that the
following applies.

For best performance between client and server, I have found that it
is best to keep the core business logic on the server, and interact
with it using something akin to a web service.

For example, rather than carrying out a series of transactions such
as :

1. Read Customer Record
2. Get next invoice no
3. Create Invoice Record
4. Write Customer Record
5. Update Customer Record with invoice history
6. write customer record.

Which involves 6 interactions with the server which are all "low-
level" read-writes. It is better to simply write a single transaction
which simply calls a databasic program on the server to "Update
Customer x With this sale" which does all the 6 steps in one go and
returns the success or error. Similarly, for user-interface
purposes where compiling data from multiple records for display, I've
always found it better to create a "virtual" single data structure
that is compiled on the server by a "call", which compiles the data on
the server and then returns in one go. This involves a little more
programming work, but will increase performance of the application
from the use-perspective many-fold.

Actually, I was about to start re-writing my vb.net based dynamic
array code and was also thinking about how to represent the data
structure. I'm also going to represent the dynamic array as a
string and use dotnet's extremely fast string handling code to
manipulate it. This is on the basis that most dynamic arrays are
relatively short (<100k). There will only be one exception that I'm
making, which is where the dynamic array contains information such as
a "report" which I is represented as a read-only dynamic array, with
attributes being a line of the report, and values being the columns.
These arrays can get big and I don't want to use standard dynamic
array handling to work with them which will be slow - I will convert
this immediately into a collection with each line being a fixed sized
array (of the number of columns). This will vastly speed up the
performance of generating reports (I convert the dynamic array into a
dataset for onward manipulation by standard dotnet controls).

Simon



On Aug 16, 12:09 pm, Tony Gravagno
wrote:
> >"Gene" wrote
> >> While the communication rate between the host and the server
> >> is utter crap[*], the data manipulation objects are top notch...
> >> * - In my personal experience even the C4 version of the D3 ODBC
> >> interface
> >> (VB5) beats the snot out of the communication speed of mv.Net.
>
> "Bill H" responded:
>
> >I've been using mv.NET for awhile on UniData and have found the
> >communication speed refreshingly fast.

[snipped]

On Aug 17, 7:14*pm, Simon wrote:


: Which involves 6 interactions with the server which are all "low-
: level" read-writes. *It is better to simply write a single
transaction
: which simply calls a databasic program on the server to "Update
: Customer x With this sale" which does all the 6 steps in one go and
: returns the success or error. * *

I agree to a point, BUT the reality is that I would expect that the
ferification of a customer code would take place erly on in the
invoice entry process --> I want to not only KNOW that I have entered
a valid customer code, but also visually VERIFY I have selected the
RIGHT customer by seeing name/address details etc displayed. Likewise,
If I'm building up a stock invoice, I'm going to want to see that I've
selected the right product line at a time, and also probably access m
y host based pricing rules which can be "complex", including quantity
breaks, mixed product discount dealks etc



: * *I'm also going to represent the dynamic array as a
: string and use dotnet's extremely fast string handling code to
: manipulate it.

When the compiler people get around to taking advantage of the new
instructions available on the next generation of Intel chips to be
released (which includes support of string searches as a single
instruction at the silicon level --> vultures anyone?) this will only
get faster