File I/O ?????

Anyone understand what this means?

Specifically, what class library are they refering to, who writes it, in
what language, and how does it work? Why would anyone want to use a
different I/O library?

From Microsoft's white paper:

File I/O
Visual Basic 6.0
File I/O statements are included in the language.
Visual Basic.NET
File I/O operations are available through class libraries. Removing the
file I/O statements from the language allows different I/O libraries to be
easily used from Visual Basic.NET. This would be more awkward if the file
I/O statements were in the language, since identifiers like Open, Close,
Print, and Write would be reserved words.
Upgrade
Wizard The file I/O statements are upgraded to the corresponding functions.
For example, the following code:
Open "MyFile.txt" For Input As #1
is upgraded to:
FileOpen( 1, "MyFile.txt", OpenMode.Input )

Gary Nelson <gn@contanet.es> wrote:
> Anyone understand what this means?
>
> Specifically, what class library are they refering to,

Mostly the .NET framework, but they also wanted to allow libraries
written in vb.NET to have Open and Close methods, which would be at
worst impossible and at best annoying if Open and Close were reserved
words.

> who writes it,

Microsoft

> in what language,

C++ and/or C#

> Why would anyone want to use a different I/O library?

Because there are a lot of things that are a pain to do using the native
VB6 I/O methods, and so have be done through API calls or the relatively
new FileSystemObject.

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

David,

>
> Because there are a lot of things that are a pain to do using the native
> VB6 I/O methods, and so have be done through API calls or the relatively
> new FileSystemObject.
>

I suppose for a beginning programmer the I/O methods in VB6 can be a pain,
but not to an experienced programmer. Since I've been programming since
basic-a, I've designed all of my own database functions in pure BASIC (now
VB6). I have many users that have databases with over half a milllion
records, some over a million. Some have as many as 20 operators attacking
the database simultaneously. Access times are about .001 second to find an
indexed record (the indexes are b-tree, also made in pure VB), and in less
than 20 seconds I can find any part of anything in the database. All of
that is done in pure VB. Many people ignore that the file I/O methods in VB
are extreemly efficient. It is absolutely impossible to do anything similar
in Access. In my tests Access not only is too slow on the non-indexed
searches (exponentially), but it crackes up after you get over five users on
it.

What does Microsoft want me to do, change to Delfi?

Gary

Gary Nelson <gn@contanet.es> wrote:
> David,
>
> > Because there are a lot of things that are a pain to do using the native
> > VB6 I/O methods, and so have be done through API calls or the relatively
> > new FileSystemObject.
> >
>
> Since I've been programming since
> basic-a, I've designed all of my own database functions in pure BASIC (now
> VB6). I have many users that have databases with over half a milllion
> records, some over a million. Some have as many as 20 operators attacking
> the database simultaneously. Access times are about .001 second to find an
> indexed record (the indexes are b-tree, also made in pure VB), and in less
> than 20 seconds I can find any part of anything in the database. All of
> that is done in pure VB. Many people ignore that the file I/O methods in VB
> are extreemly efficient. It is absolutely impossible to do anything similar
> in Access. In my tests Access not only is too slow on the non-indexed
> searches (exponentially), but it crackes up after you get over five users on
> it.

MichKa, here's another 'Jet doesn't scale' guy to pick on...

More seriously, I'm pretty sure that the old VB I/O functions are in
either the compatibility namespace or the VB namespace, but you'll
probably find the functions in System.IO to be more effecient and more
powerful in vb.NET.

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

David,

What gets me is why does Microsoft have to take funcionality out of the
language, which takes little programming on their behalf, and gives us great
headaches.

I mean, I already had to create functions to emulate MKD, CVD, etc. when
Microsoft took them out of VB. I am sure that MKD in assembler or C can be
no more that two or three lines of code. Why kill it? Now I hear they are
killing LSET. I mean, I use it for a lot of things. Now I have to create a
function to emulate it. Again, how much code does LSET take???

About Jet, try doing a secuencial search on a part of a field that isn't
indexed on a million key database. You just as well got to lunch while you
wait.

Gary

Gary Nelson <gn@contanet.es> wrote:
> David,
>
> What gets me is why does Microsoft have to take funcionality out of the
> language, which takes little programming on their behalf, and gives us great
> headaches.
>
> I mean, I already had to create functions to emulate MKD, CVD, etc. when
> Microsoft took them out of VB. I am sure that MKD in assembler or C can be
> no more that two or three lines of code. Why kill it? Now I hear they are
> killing LSET. I mean, I use it for a lot of things. Now I have to create a
> function to emulate it. Again, how much code does LSET take???

vb.NET is a ground-up rewrite. And you should never do a ground-up
rewrite of a large project unless you absolutely have to, because it's
impossible to do without annoying a lot of your customers. Microsoft
knows this, which is why they put off doing a ground-up rewrite of VB
for so long. And they're going to annoy a lot of their best customers
anyway.

Because Microsoft actually has to ship vb.NET at some point, and they
actually want to sell it, cool new features are going to be higher-
priority than rarely-used features. You simply can't rebuild all the
features of VB1 through VB6, add on all the functionality of a modern OO
language, and build the .NET class libraries in a decent timeframe. Half
the reason for the whole CLR/.NET framework, IMO, is so that Microsoft
only has to build one class library, instead of three or four. Microsoft
may have more resources than any other software company, but those
resources are still finite.

For a programming language, rarely-used features that academic computer
scientists -- and the young people who with CS degrees at Microsoft --
consider to be evil, patheitc hacks, Microsoft won't think very long
about cutting them. LSet, GoSub, and the like are those kind of
features. That doesn't mean that you don't find them useful, or that
they're never useful, but they're the kind of construct that I'd never
even consider using because I just wouldn't think of it.

--
Dave Rothgery
Picking nits since 1976
drothgery@myrealbox.com
http://drothgery.editthispage.com

"Gary Nelson" <gn@contanet.es> wrote in message <news:3a92a328@news.devx.com>...

> About Jet, try doing a secuencial search on a part of a field that isn't
> indexed on a million key database. You just as well got to lunch while you
> wait.

What did the code look like? There are a number of pretty straightforward
tricks that do speed things up quite a bit, such as creating aliases for
frequently accessed fields so you aren't constantly hitting the Fields
collection.

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

MichKa,

> Oh, how very fair and accurate of a report. Compare your b-tree index
system
> to unindexed rows. Is that how you need to convince yourself that your own
> way is better?

In my post I said:

<<Access times are about .001 second to find an
indexed record (the indexes are b-tree, also made in pure VB), and in less
than 20 seconds I can find any part of anything in the database. >>

The 20 seconds is on an unindexed row as you call it.

Gary

Joe,

> What did the code look like? There are a number of pretty straightforward
> tricks that do speed things up quite a bit, such as creating aliases for
> frequently accessed fields so you aren't constantly hitting the Fields
> collection.

Actually it's not really very hard to do. Open the file in binary, read in
64K segments, use INSTR to find what your looking for (case sensitive is
incrediblly fast, case insensitive takes a little longer), calculate what
record you have hit, and pull the whole record. I just did a test to time a
search. A database with 326,265 records, 47 MB in size, a secuencial search
can done be done on a non indexed field in a little less than 8 seconds, and
that is on my old 300 mhz. notebook. A case insensitive search (look for
John and pick up john or JOHN) took a little over 30 seconds. A search for
a double precision number both positive and negative takes about 12 seconds.

I use the rutine on my own databases, but it can also be used on DBase
files, and I have also used it on Btrieve files. Btrieve files take a little
more work as you have to filter the index pages, but it is still very
efficient. (My brother works with Btrieve, and has a shareware program to
handle the files). Once I asked Microsoft for the internal structure of the
Access database to build a rutine to do the same, but they wouldn't give it
to me, and I wasn't in the mood to crack it (besides which they change it
too often).

Let me know if you want a copy of the code, it's only about 30 lines long.

Gary

"Gary Nelson" <gn@contanet.es> wrote in message <news:3a96af73@news.devx.com>...

> Joe,
>
> > What did the code look like? There are a number of pretty straightforward
> > tricks that do speed things up quite a bit, such as creating aliases for
> > frequently accessed fields so you aren't constantly hitting the Fields
> > collection.
>
> Actually it's not really very hard to do. Open the file in binary, read in
> 64K segments, use INSTR to find what your looking for (case sensitive is
> incrediblly fast, case insensitive takes a little longer), calculate what
> record you have hit, and pull the whole record. I just did a test to time a
> search. A database with 326,265 records, 47 MB in size, a secuencial search
> can done be done on a non indexed field in a little less than 8 seconds, and
> that is on my old 300 mhz. notebook. A case insensitive search (look for
> John and pick up john or JOHN) took a little over 30 seconds. A search for
> a double precision number both positive and negative takes about 12 seconds.

Sorry, I was asking about the "go to lunch" slow Jet code. However,
just how smart is the InStr builtin, anyway? There's a way to examine
only every Len(string2)-th character in string1 instead of every
character, but in this case, the disk access times will probably
overwhelm anything gained by a smarter InStr.

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Joe,

> However,
> just how smart is the InStr builtin, anyway? There's a way to examine
> only every Len(string2)-th character in string1 instead of every
> character, but in this case, the disk access times will probably
> overwhelm anything gained by a smarter InStr.


A$=space$(65534)
B$="Find Me"
open "Filename" for binary as 1
do while not eof(1)
get 1,,a$
if instr(a$,b$)<>0 then
' use seek to find where you are
' separate record, etc.
end if
loop

Gary

> A$=space$(65534)
> B$="Find Me"
> open "Filename" for binary as 1
> do while not eof(1)
> get 1,,a$
> if instr(a$,b$)<>0 then
> ' use seek to find where you are
> ' separate record, etc.
> end if
> loop

That's interesting. What if my record length isn't a factor of 65534 and the
string to be found is split?

> That's interesting. What if my record length isn't a factor of 65534 and
the
> string to be found is split?
>


There are two different things you can do. First I chose 65534 because
exact multiples of cluster sizes read faster from the hard disk, but it is
not necessary to do so. You can read a multiple of your record length, or
you can take into consideration that the last record in the string is not
complete.

The string doesn't have to be that large either. Sometimes around 32K
produces faster results. Or the exact cluster size of the hard disk in
question.Generally strings larger than 64K slow down as VB has a harder time
handling them.

Gary

> Nah, no picking. I just resign myself to the fact that some people just
> don't know how to do stuff.
>
> After all, he did compare his proprietary index system to an unindexed
> million row table. So he must know what he is talking about. I am sure his
> database system provides all of the features and all of the connections to
> other data sources/encodings that Jet does too.
>
MichKa,

Like decent record locking. Actually, my database includes field locking,
permitting multiple users to update different fields of the same record
simultaneously.

Or how about reading an individual field of a record of a database without
reading in the entire record. Or how about updating an individual field of
a database without touching the rest of the record.

Gary

And 65534 is an exact multiple of which cluster size?

Rune
"Gary Nelson" <gn@contanet.es> wrote in message
news:3a9a5d03@news.devx.com...
> > That's interesting. What if my record length isn't a factor of 65534 and
> the
> > string to be found is split?
> >
>
>
> There are two different things you can do. First I chose 65534 because
> exact multiples of cluster sizes read faster from the hard disk, but it is
> not necessary to do so. You can read a multiple of your record length,
or
> you can take into consideration that the last record in the string is not
> complete.
>
> The string doesn't have to be that large either. Sometimes around 32K
> produces faster results. Or the exact cluster size of the hard disk in
> question.Generally strings larger than 64K slow down as VB has a harder
time
> handling them.
>
> Gary
>
>