File I/O ?????

[Joe \Nuke Me Xemu\ Foster]

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

> 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

And this answers either of my questions how, exactly...? If the Access/
Jet/VBA code against which you're comparing your "solution" is equally
innovative, no wonder it was getting nowhere fast.

--
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 \Nuke Me Xemu\ Foster]

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

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

Your "field locking" implies fixed string lengths, does it not? That
can be pretty wasteful, especially if, say, most last names are like
"Jones" and "Smith" while only a few are real jawbreakers. OTOH, you
could go with partial replication and smart update conflict resolution
which you'll need anyway if you want to support mobile users, and even
page locking, with its low overhead, will work well in that scenario.

> 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.

If you want DBFs, use DBFs. At least there are ODBC and perhaps ADO
providers for them. Unfortunately, that doesn't give you good vendor
lock-in, does it?

--
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!

[Gary Nelson]

Joe,

> Your "field locking" implies fixed string lengths, does it not? That
> can be pretty wasteful, especially if, say, most last names are like
> "Jones" and "Smith" while only a few are real jawbreakers. OTOH, you
> could go with partial replication and smart update conflict resolution
> which you'll need anyway if you want to support mobile users, and even
> page locking, with its low overhead, will work well in that scenario.

With todays hard disk sizes, that is not a real problem. Very few of my
clients have databases that pass 100 MB, and numeric fields (which is where
conflicts arise) are always fixed length.

I don't even bother to lock string fields. Why?

Say two people modify the same account simultaneously.

Original account: John Smith

User one changes that to: John L. Smith

User two changes that to: John W. Smith

Why bother to lock? Their problem is not record locking but rather their
own internal organization.

Where the problem occurs is when two people make entries into the monthly
balance of an account simultaneously, and the monthly balance must be
updated by both.

> If you want DBFs, use DBFs. At least there are ODBC and perhaps ADO
> providers for them. Unfortunately, that doesn't give you good vendor
> lock-in, does it?

I provide export-import in DBF, Ascii and even Access. I also provide an
Ole Server so third parties can access the database.

Gary

[Gary Nelson]

> And 65534 is an exact multiple of which cluster size?

Go to MSDOS and do a chkdsk on your hard drive. You'll probably find that
64K can be divided by the cluster size of your hard disk.

Some are 4K, 16K, even 32K.

Gary

[Gary Nelson]

Joe,

> And this answers either of my questions how, exactly...? If the Access/
> Jet/VBA code against which you're comparing your "solution" is equally
> innovative, no wonder it was getting nowhere fast.

I didn't say it was innovative, I just said it was fast. As I said, it is
actually quite simple, which is why I can't figure out why something similar
has not been implemented in Access. With just a couple of hours of coding
Access could really fly instead of limp along.

It's like I said above about field locking. How hard would it be to
implement field locking in Access. Actually it should be as easy as pie,
even if you don't use fixed length strings. How hard is it to locate the
exact position of a certain string in a database. If you've created the
database (MS - Access), you can locate it's position in a small fraction of
a second, locking that position is a no-brainer.

My position on this has always been that Microsoft doesn't fix the defects
in Access to force people to SQL.

Gary

[Bob Butler]

"Gary Nelson" <gn@contanet.es> wrote in message
news:3a9cddc3@news.devx.com...
> > And 65534 is an exact multiple of which cluster size?
>
> Go to MSDOS and do a chkdsk on your hard drive. You'll probably find that
> 64K can be divided by the cluster size of your hard disk.
>
> Some are 4K, 16K, even 32K.

I think the point is that 65534 is not a multiple of those values. 65536
would be another matter.

[Rune Bivrin]

Something like that, yes...

Having written a low-level HDD interleave changing app in Turbo Pascal way
back in '87, and subsequently trashing my own, just because I didn't realize
XT and AT had different interfaces for INT14 (or whatever it was), I'm kind
of sensitive to the minor details of disks.
It also provides a foundation for the appreciation of interface
immutability.

Rune Bivrin
"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3a9d15d7@news.devx.com...
>
> "Gary Nelson" <gn@contanet.es> wrote in message
> news:3a9cddc3@news.devx.com...
> > > And 65534 is an exact multiple of which cluster size?
> >
> > Go to MSDOS and do a chkdsk on your hard drive. You'll probably find
that
> > 64K can be divided by the cluster size of your hard disk.
> >
> > Some are 4K, 16K, even 32K.
>
> I think the point is that 65534 is not a multiple of those values. 65536
> would be another matter.
>
>
>

[Joe \Nuke Me Xemu\ Foster]

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

> Joe,
>
> > And this answers either of my questions how, exactly...? If the Access/
> > Jet/VBA code against which you're comparing your "solution" is equally
> > innovative, no wonder it was getting nowhere fast.
>
> I didn't say it was innovative, I just said it was fast. As I said, it is

The 65534 chunk size is certainly "innovative". Why &HFFFE& and not a
power of two? I'll assume the code to cope with the possibility of the
string you want being split over two Gets was ommitted along with the
error checking.

> actually quite simple, which is why I can't figure out why something similar
> has not been implemented in Access. With just a couple of hours of coding
> Access could really fly instead of limp along.

What limps along is many people's use of DAO, which is why I keep asking
to see the code against which you're comparing the snippet you actually
did post. Some of the techniques for getting the most out of DAO and Jet
hadn't been discovered until years after they were first possible, like
any other programming idiom, I suppose.

> It's like I said above about field locking. How hard would it be to
> implement field locking in Access. Actually it should be as easy as pie,

What business problem does field locking really solve? Once one has the
epiphany that database locks of any sort and waiting for users don't mix,
much of the wanking over even record locking seems rather hollow.

> even if you don't use fixed length strings. How hard is it to locate the
> exact position of a certain string in a database. If you've created the
> database (MS - Access), you can locate it's position in a small fraction of
> a second, locking that position is a no-brainer.
>
> My position on this has always been that Microsoft doesn't fix the defects
> in Access to force people to SQL.

Does SQL Server use field locking, then?

--
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!

[Sjoerd Verweij]

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

Just out of masochistic curiosity, how is that implemented?

[Joe \Nuke Me Xemu\ Foster]

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

> With todays hard disk sizes, that is not a real problem. Very few of my
> clients have databases that pass 100 MB, and numeric fields (which is where
> conflicts arise) are always fixed length.

How fortunate that you have the luxury of thinking that small databases
will stay small.

> I don't even bother to lock string fields. Why?
>
> Say two people modify the same account simultaneously.
>
> Original account: John Smith
>
> User one changes that to: John L. Smith
>
> User two changes that to: John W. Smith
>
> Why bother to lock? Their problem is not record locking but rather their
> own internal organization.

If nothing else, being able to notice this is useful in diagnosing the
organizational problem.

> Where the problem occurs is when two people make entries into the monthly
> balance of an account simultaneously, and the monthly balance must be
> updated by both.

Human operators are directly modifying account balances? Call a criminal
defense attorney familiar with tax law NOW!

--
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!

[Gary Nelson]

> > Like decent record locking. Actually, my database includes field
locking,
> > permitting multiple users to update different fields of the same record
> > simultaneously.
>
> Just out of masochistic curiosity, how is that implemented?
>

Actually it's not difficult at all. When you open a fine in binary you can
lock any position in the file, from byte to byte. So it's just a simple
matter to calculate where the field to be updated is located in the file,
and lock the respective bytes. This is the sub I use:


Sub Lockfield(FI%, Nnreg&, Optional fromFIELD, Optional toFIELD)
On Error GoTo errorlock
Dim fField As Integer
Dim tField As Integer
If IsMissing(fromFIELD) Then
fField = 1
tField = TP(FI)
ElseIf IsMissing(toFIELD) Then
fField = fromFIELD
tField = fromFIELD
Else
fField = fromFIELD
tField = toFIELD
End If
npos1& = (Nnreg& - 1) * REGLEN(FI) + 1 + O(FI, fField)
npos2& = (Nnreg& - 1) * REGLEN(FI) + O(FI, tField + 1)
Lock FI%, npos1& To npos2&
Exit Sub

errorlock:

errlock% = errlock% + 1
If errlock% > 500 Then MsgBox k(153), 48
Resume

End Sub

[Gary Nelson]

Joe,

>
> The 65534 chunk size is certainly "innovative". Why &HFFFE& and not a
> power of two? I'll assume the code to cope with the possibility of the
> string you want being split over two Gets was ommitted along with the
> error checking.

Oops.. I pulled the number out of my head. The right number is 65536

> What business problem does field locking really solve? Once one has the
> epiphany that database locks of any sort and waiting for users don't mix,
> much of the wanking over even record locking seems rather hollow.
>

When you have a lot of users attacking the database you need to keep it as
free as possible. Field locking avoids a lot of simultaneous hits.

> Does SQL Server use field locking, then?

Not as far as I know. But it does seem to handle a lot of users better than
Access.

Gary

[Gary Nelson]

Joe,

> How fortunate that you have the luxury of thinking that small databases
> will stay small.

It all depends on what has to go into the database. You can stick a lot of
data in 100MB, not so images,etc.

>
> Human operators are directly modifying account balances? Call a criminal
> defense attorney familiar with tax law NOW!
>

We are talking about a relational database. The human operators make
entries into the entry table, internally the program updates the monthly
balance table. The details of each entry are recorded including the
operator who made the entry, each entry has a document number related to the
paper document which justifies the entry. You don't get clients with 20
operators inserting entries in a 100 MB database if you do stupid things.

Gary

[Gary Nelson]

Bob,
> I think the point is that 65534 is not a multiple of those values. 65536
> would be another matter.

Sorry about that, I pulled the number off the top of my head and got it
wrong. You are correct.

Gary

[Joe \Nuke Me Xemu\ Foster]

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

> Joe,
>
> > How fortunate that you have the luxury of thinking that small databases
> > will stay small.
>
> It all depends on what has to go into the database. You can stick a lot of
> data in 100MB, not so images,etc.

BLOBs probably belong in separate files in a shared folder to which only
the data tier has write and search access. Other tiers should have only
read access but not even the right to scan the directory. There are ways
to implement transaction compatibility with this scheme, such as writing
changes into a new file and never deleting the old until after the next
backup or two after the commit.

> >
> > Human operators are directly modifying account balances? Call a criminal
> > defense attorney familiar with tax law NOW!
> >
>
> We are talking about a relational database. The human operators make
> entries into the entry table, internally the program updates the monthly
> balance table. The details of each entry are recorded including the
> operator who made the entry, each entry has a document number related to the
> paper document which justifies the entry. You don't get clients with 20
> operators inserting entries in a 100 MB database if you do stupid things.

Fine, but do you still have hot spots in the balance table? When are you
going to show me the Access/DAO/Jet code that you claim proves searching
MDBs is "go to lunch" slow? Should we move this to some other forum?

--
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!