File I/O ????? - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 33

Thread: File I/O ?????

  1. #16
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

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



  2. #17
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

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



  3. #18
    Gary Nelson Guest

    Re: File I/O ?????

    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



  4. #19
    Gary Nelson Guest

    Re: File I/O ?????

    > 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



  5. #20
    Gary Nelson Guest

    Re: File I/O ?????

    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



  6. #21
    Bob Butler Guest

    Re: File I/O ?????


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




  7. #22
    Rune Bivrin Guest

    Re: File I/O ?????

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




  8. #23
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

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



  9. #24
    Sjoerd Verweij Guest

    Re: File I/O ?????

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




  10. #25
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

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



  11. #26
    Gary Nelson Guest

    Re: File I/O ?????


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







  12. #27
    Gary Nelson Guest

    Re: File I/O ?????

    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



  13. #28
    Gary Nelson Guest

    Re: File I/O ?????

    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



  14. #29
    Gary Nelson Guest

    Re: File I/O ?????

    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



  15. #30
    Joe \Nuke Me Xemu\ Foster Guest

    Re: File I/O ?????

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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center