DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

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

Thread: Best data transfer method

  1. #16
    Richard Dalton . Guest

    Re: Best data transfer method


    <Darin> wrote:
    >I've noticed a lot of discussion about purity in OO designs. It >kind of

    strikes me like guys I know that choke when they see a >DB that's not third
    normal form.

    Yeah it's kind of like that, but the really good guys know
    when a bit of unnormalization is justified. The Normal form
    rules are basically a way to teach chimps to design a database.

    Any good DB designers have an instinctive grasp of it and
    probably couldn't tell you the rules for each normal form.
    That instinct also allows them to ditch the rules in favour
    of performance when the need arises.

    I think the same thing applies to any design effort. There
    are rules that allow almost anyone to design something that
    will fundamentally work, but experience and a natural
    understanding allows you to break the rules in the interests of
    a better design.

    Perhaps creativity is the ability to break the right rules.


    >But what if you want to add a field to the DB and you want the >client to

    see it. All **** breaks loose. You've got interfaces >that have to be extended
    and or broken etc.

    OK. I agree with a lot of what you say, but this issue
    is a pet peeve of mine, so indulge me here.

    Let's say we have our old faithful Employee table. And
    we have a number of fields. We build our Middle Tier
    and the UI.

    Presumably if we are building any sort of Object Oriented
    model we will have an employee object with probably a property
    per field.

    Our UI is likely to have a form for editing the employee
    with text boxes for each property/db field.

    Now if you change the Employee table. Whatever way you do it,
    you will need to add a property to the Employee object to
    provide access to the field. You are also going to need to
    change the UI so that it has access to the new property.

    I think you are suggesting cutting out the object and bringing
    the Employee recordset straight back to the UI so the only
    thing that changes is the UI. I'm just not sure I agree with
    you.

    First of all changes to individual tables in the underlying
    database are fairly rare. Sure you'll add new tables.
    You'll sometimes modify a table but it is rare.

    The idea of middle tier objects is that you can write them
    once, model relationships and business rules and then reuse
    them. You lose that if every UI programmer has to use SQL
    and deal directly with the DB.

    The effort to change a middle tier object to add a field
    is significantly less than having to talk directly to the
    database every time.

    Finally think about the type of people who will be dealing with
    your database. A new recruit joins your company, writes
    a program to update some table, but doesn't know that when
    updating that table you also need to modify or check a second table to enforce
    some business rule.

    By giving new recruits a domain object model to work with you
    hide the details. Data Hiding is why I build a middle
    tier. Performance and scalability are nice but secondary
    benefits.

    >In the end, I don't look at it as "passing recordsets to the >client", I

    look at it as, "passing a persisted block of data to >the client, and using
    a sophisticated library at the client to >manipulate that data".

    That's fine and I agree. But the library you talk about is a
    generic Database library. All it gives you is the ability
    to manipulate tables and records. It can't enforce business
    rules, and you really need to know your way around the database.

    I know SQL quite well, but if I joined your company how long
    would it take me to come up to speed on your databases so I
    could be productive?


    -Richard


  2. #17
    Jason Langston Guest

    Re: Best data transfer method

    Richard,
    Comments inline :

    <Richard Dalton .> wrote in message news:3a77ea1f$1@news.devx.com...
    <snip>
    > The idea of middle tier objects is that you can write them
    > once, model relationships and business rules and then reuse
    > them. You lose that if every UI programmer has to use SQL
    > and deal directly with the DB.


    Exactly. Especially if you have several different UI's (views) that all use
    basically the same underlying business objects. The data-tier is supposed to
    be for storage, therefore relatively ignorant of the business rules. If
    every UI programmer is dealing directly with "raw" data via a recordset
    (marshalled however you want) that would mean each UI programmer must know
    and apply the appropriate business rules. If a business rule changes, now
    you must update each seperate UI.

    For example, the Employee object you mentioned. I may have a Human Resources
    app that needs access to all of the Employee data, a Managers app that
    accesses limited data (salary, hire date, etc. but not say date-of-birth)
    for each employee they manage, and a general "phonebook" web-app available
    to everyone. Each of these UI's should act as the filter for the data the
    user sees. That could be accomplished by each UI directly manipulating
    recordsets.
    But now suppose the Employee object should have a .NextReviewDate property.
    Our company's business rule is that this is calculated by adding one year to
    the LastReviewDate (LastReviewDate is stored in the database). So I add this
    calculation in the HR app, and the Managers App. Tomorrow the BusinessRule
    changes, reviews should be every three months. Now go back and change both
    apps. If the apps instead were accessing an object which encapsulated the
    business rule, all I'd have to do is change the business object, the UI's
    would chug on oblivious to the change.
    Obviously this example is over simplified, but I think it makes the point.

    > The effort to change a middle tier object to add a field
    > is significantly less than having to talk directly to the
    > database every time.
    >
    > Finally think about the type of people who will be dealing with
    > your database. A new recruit joins your company, writes
    > a program to update some table, but doesn't know that when
    > updating that table you also need to modify or check a second table to

    enforce
    > some business rule.


    Philosophical question : Would you consider business logic in stored
    procedures and triggers as the logical business layer? It would certainly
    accomplish the "data hiding"/encapsulation. It would be difficult to later
    seperate to a different machine for scalability, but ...

    Personally, I feel that how the data is stored should be completely unknown
    at the business layer. Is CEmployee's properties stored in one table or four
    well-normalized tables? At the business layer I shouldn't care. I should ask
    the Data Access layer for CEmployee's data. It should return all that data.
    If weeks from now my DBA (me in the real world) realizes it's time to
    de-normalize those four tables into three for better performance, I should
    be able to modify the Data Access layer, and the business layer never
    changes.

    > By giving new recruits a domain object model to work with you
    > hide the details. Data Hiding is why I build a middle
    > tier. Performance and scalability are nice but secondary
    > benefits.
    >
    > >In the end, I don't look at it as "passing recordsets to the >client", I

    > look at it as, "passing a persisted block of data to >the client, and

    using
    > a sophisticated library at the client to >manipulate that data".
    >
    > That's fine and I agree. But the library you talk about is a
    > generic Database library. All it gives you is the ability
    > to manipulate tables and records. It can't enforce business
    > rules, and you really need to know your way around the database.


    Agreed again. See my example above.

    -Jason



  3. #18
    Guest

    Re: Best data transfer method

    > The idea of middle tier objects is that you can write them
    > once, model relationships and business rules and then reuse
    > them. You lose that if every UI programmer has to use SQL
    > and deal directly with the DB.


    Ah but you miss my point. The client +does not+ ever connect directly to the
    DB. That's the beauty of disconnected recordsets. The client doesn't ever
    really even code up SQL at all. The recordset is just a bag, much like a
    property bag, or a UDT.

    The client makes a request of the middle tier in the same fashion as what's
    been described here many times, but the middle tier gives back a
    disconnected RS, not some copy of it in a UDT or property bag.

    The client never has access to the database, never executes stored procs,
    normally doesn't even have rights to connect to the db. All that is handled
    by a middle tier.


    > That's fine and I agree. But the library you talk about is a
    > generic Database library. All it gives you is the ability
    > to manipulate tables and records. It can't enforce business
    > rules, and you really need to know your way around the database.


    That's what that middle teir is for. The generic database library, however,
    is awfully handy at manipulating those records.


    > I know SQL quite well, but if I joined your company how long
    > would it take me to come up to speed on your databases so I
    > could be productive?


    Actually, we just recently hired two guys about 2 months ago. Both were
    graduates of the, now-defunct, CLC (Computer Learning center). By their own
    admission, it was expensive and they didn't learn that much. But they'd both
    dabbled in programming and both knew some VB. Niether had any professional
    programming experience. This project is a commercial app, currently about
    90000 lines of VB (I used Project Analyzer a few days ago, so I happen to
    know numbers<g>).

    I started both on bug fixing on the client side. They were productive after
    about three weeks.

    One is still working bugs on the client side and adding features. The other
    graduated to the middle tier and the back end (SQL, stored procs and some
    background, service programs).

    They didn't have to know anything about the DB to be productive. (they did
    have to learn our coding standards, development directory structure, layout
    of the servers, how to use Visual SourceSafe, and how to build a machine
    from a box of parts. Everyone that I hire gets to build their own machine on
    their first day.)

    I'd say they spent more time on that than on learning the DB.





  4. #19
    Deborah Guest

    Re: Best data transfer method

    I may be too late here, but I read through the current discussion and was
    surprised that XML was not discussed further.

    I think the *only* answer today should be XML. The reasons for this are
    many, in no particular order:

    1) .NET, the next version of VB, won't support variant arrays
    2) .NET is moving away from ADO recordsets.
    3) All of .NET is based on XML.
    4) More importantly, XML is platform independent, so it can be passed to
    clients (or other servers) that are not MS platforms.
    5) You can leverage XSL for filtering and sorting that you cannot do with
    variant arrays.
    6) The code receiving the recordset does not need access to the ADO DLLs.
    (This was important for one of our clients whereby the OLE-DB DLL version on
    user's machines was a problem.)

    Just my thoughts -
    Deborah

    "Dennis" <dbronstein@brainranger.com> wrote in message
    news:3a6ca520$1@news.devx.com...
    > We are building a standard 3-tier web app. We are trying to determine the
    > best way to transfer data from the middle tier components to the UI. We
    > have been testing to compare disconnected ADO recordsets, XML, and variant
    > arrays. In our testing with the components on a separate server from the
    > UI, arrays blow recordsets and XML out of the water. A call to return an
    > array runs at about 18-19 milliseconds. Calls for recordsets and XML run
    > about 32-34 ms.
    >
    >




  5. #20
    Hilmar Retief Guest

    Re: Best data transfer method


    <Richard Dalton .> wrote in message news:3a77ea1f$1@news.devx.com...

    > Let's say we have our old faithful Employee table. And
    > we have a number of fields. We build our Middle Tier
    > and the UI.
    >
    > Presumably if we are building any sort of Object Oriented
    > model we will have an employee object with probably a property
    > per field.


    Agreed. And the additional benefit ofcourse, is that any client-side
    validation can be inserted here too. One of the benefits of using OO style
    properties iso accessing the RS directly from the UI.

    > Our UI is likely to have a form for editing the employee
    > with text boxes for each property/db field.
    >
    > I think you are suggesting cutting out the object and bringing
    > the Employee recordset straight back to the UI so the only
    > thing that changes is the UI. I'm just not sure I agree with
    > you.


    This would be contrary to efforts in creating an abstraction layer between
    DB and UI, as well as nullify the advantages gained from multi-tier
    architecture, i.e. scalability etc.

    > The idea of middle tier objects is that you can write them
    > once, model relationships and business rules and then reuse
    > them. You lose that if every UI programmer has to use SQL
    > and deal directly with the DB.
    >


    Depending on the client (win32 or Browser), a compromise may be in order
    here (especially for display/list type information). If your client
    developer is building a win32 type (like a VB form), he wil be able to be
    more productive by making use of RS bound controls, while most web
    developers will probably not care either way, since they generally will have
    to loop thru the returned dataset anyway (collection or RS).

    > The effort to change a middle tier object to add a field
    > is significantly less than having to talk directly to the
    > database every time.
    >
    > Finally think about the type of people who will be dealing with
    > your database. A new recruit joins your company, writes
    > a program to update some table, but doesn't know that when
    > updating that table you also need to modify or check a second table to

    enforce
    > some business rule.
    >
    > By giving new recruits a domain object model to work with you
    > hide the details. Data Hiding is why I build a middle
    > tier. Performance and scalability are nice but secondary
    > benefits.
    >

    Exactly!

    > >In the end, I don't look at it as "passing recordsets to the >client", I

    > look at it as, "passing a persisted block of data to >the client, and

    using
    > a sophisticated library at the client to >manipulate that data".
    >
    > That's fine and I agree. But the library you talk about is a
    > generic Database library. All it gives you is the ability
    > to manipulate tables and records. It can't enforce business
    > rules, and you really need to know your way around the database.


    One of the good things of providing both (a read only view of the recordset
    and a collection object), is that the UI developer can make use of all the
    features coming along with disc rs' as well as making use of databound
    controls to display / list the information. These controls may already
    include much requested features like sorting, grouping etc.
    However, I'm in agreement with the fact that any updating should occur thru
    a abstraction layer provided by the use of OO style properties and methods.

    Hilmar



  6. #21
    Richard Dalton . Guest

    Re: Best data transfer method


    "Deborah" <Deborahk@insteptech.com> wrote:
    >I think the *only* answer today should be XML. The reasons for this are
    >many <snip>


    Yep. I agree. To your list I would add another...
    It's natural hierarchical structure makes it ideal for serialising
    complete object hierarchies (If you have any - But that's another debate!)

    -Richard


  7. #22
    Richard Dalton . Guest

    Re: Best data transfer method


    Hilmar, thanks for that. It's an interesting approach,
    bringing a recordset all the way to the UI as a read only
    view of the data, but doing updates through the object model.

    I must admit I've sort of thrown the baby out with the bath water.
    In my haste to get rid of recordsets from the client, I didn't
    consider this approach.

    I'm not saying I fully agree with you though. Maybe I'll
    come round, but for the moment I'm still not 100% convinced.

    Still, you got me thinking.

    -Richard



    "Hilmar Retief" <hretief@hotmail.com> wrote:
    >However, I'm in agreement with the fact that any updating should occur >thru

    a abstraction layer provided by the use of OO style properties and methods.


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

    Re: Best data transfer method

    <Richard Dalton .> wrote in message <news:3a873416$1@news.devx.com>...

    > Hilmar, thanks for that. It's an interesting approach,
    > bringing a recordset all the way to the UI as a read only
    > view of the data, but doing updates through the object model.


    Just what is being passed through to the object model, though? I maybe
    see a timestamp, so the data tier can catch most, though not all, update
    collisions. Some collisions can slip through if you use SQL UPDATE to
    write to the database instead of recordset objects, even if you're using
    your own read-before-write checking, in this and similar scenarios:

    user a fetches record x
    user b fetches record x
    user a mashes his keyboard
    user b mashes her keyboard
    user a checks record x, sees no changes
    user b checks record x, sees no changes
    user a updates record x, hunky-dory so far
    user b updates record x, nuking user a's changes

    I figure .Edit and .Update are using wheels I don't particularly want
    to reinvent. And if the data tier detects a collision, what then? Do
    we bounce it back to the user, or do we try to merge the changes? If
    user A changed only field P and user B changed only field Q, can the
    data tier figure it out, or does it have no choice but to choke? What
    if both users change the same field, perhaps to the same value but
    perhaps not, what then? What I'm doing now involves passing around
    both the original data and the user's changes, won't let me separate
    the business and data tiers, and looks rather like a job security
    tier, all to avoid interrupting the data entry folks' work. =(

    "Grabbing my ankles so the end-users won't have to..."

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



  9. #24
    Guest

    Re: Best data transfer method

    > And if the data tier detects a collision, what then? Do
    > we bounce it back to the user, or do we try to merge the changes? If
    > user A changed only field P and user B changed only field Q, can the
    > data tier figure it out, or does it have no choice but to choke? What
    > if both users change the same field, perhaps to the same value but
    > perhaps not, what then? What I'm doing now involves passing around
    > both the original data and the user's changes, won't let me separate
    > the business and data tiers, and looks rather like a job security
    > tier, all to avoid interrupting the data entry folks' work. =(


    Its funny, but almost nothing you read discusses how to intelligently handle
    update collisions. There's a whole science involved in that one area.

    Of all the things a "middle tier" is good for, one of the biggest is
    encapsulating those collision handling rules.

    Whether you bounce stuff back to the client completely depends on the type
    of data. Whether you can merge fields depends on the type of data. yadda
    yadda. It's a big issue.

    Yet another reason I like passing disconnected recordsets back and forth
    between client and server. They automatically contain enough metadata to let
    you sort out what you need to do in cases of collisions. I remember writing
    all that code in VB3 before ADO to manage all that stuff using BTRIEVE. It
    wasn't terribly fun.

    I like ADO a lot more (though it's infuriating at times too!)



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

    Re: Best data transfer method

    <Darin> wrote in message <news:3a8b27b5$1@news.devx.com>...

    > Of all the things a "middle tier" is good for, one of the biggest is
    > encapsulating those collision handling rules.


    This is a *huge* selling point, but it applies equally well to the
    multimaster partial vertical database replication schemes I've been
    playing with. It isn't as if replication merges are more difficult,
    since almost anything can happen to a record after someone brings it
    up, starts editing, goes to lunch, comes back, edits some more, takes
    a phone call, and finally saves the changes. I guess you could use a
    "check out/check in" mechanism, but that drops deadlock resolution in
    your lap on top of everything else, aye yi yi!

    > Whether you bounce stuff back to the client completely depends on the type
    > of data. Whether you can merge fields depends on the type of data. yadda
    > yadda. It's a big issue.


    Oh, yeah. And yet, from the way so many gurus tell us to use SQL UPDATE
    statements to write the changes and all the example CRUD code you see
    floating around, you'd think this issue is being ignored altogether.
    Hulk not get it.

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



  11. #26
    Guest

    Re: Best data transfer method

    > Oh, yeah. And yet, from the way so many gurus tell us to use SQL UPDATE
    > statements to write the changes and all the example CRUD code you see
    > floating around, you'd think this issue is being ignored altogether.
    > Hulk not get it.


    Exactly. That's why I've been partial to the disconnected recordset
    marshalling idea for so long. I've written code to manage collisions before
    and you'll dang near rewrite all the RS code for tracking Current field
    values, last field values, DB Field values, field types, etc, etc.

    The only thing really missing is field grouping. IE it usually doesn't make
    any sense to "merge" addr1, addr2, city, state, and zip fields, if one user
    changed one field to one thing, and another user changed it to something
    else. The address is really a "metafield" that should be considered as a
    whole.

    ADO has those wonderful "Properties" yet you don't seem to be able to create
    your own, you get what they give you and that's it..

    Sigh....



  12. #27
    Hilmar Retief Guest

    Re: Best data transfer method


    <Darin> wrote in message news:3a8b27b5$1@news.devx.com...
    > > And if the data tier detects a collision, what then? Do
    > > we bounce it back to the user, or do we try to merge the changes? If
    > > user A changed only field P and user B changed only field Q, can the
    > > data tier figure it out, or does it have no choice but to choke? What
    > > if both users change the same field, perhaps to the same value but
    > > perhaps not, what then? What I'm doing now involves passing around
    > > both the original data and the user's changes, won't let me separate
    > > the business and data tiers, and looks rather like a job security
    > > tier, all to avoid interrupting the data entry folks' work. =(

    >
    > Its funny, but almost nothing you read discusses how to intelligently

    handle
    > update collisions. There's a whole science involved in that one area.
    >
    > Of all the things a "middle tier" is good for, one of the biggest is
    > encapsulating those collision handling rules.
    >
    > Whether you bounce stuff back to the client completely depends on the type
    > of data. Whether you can merge fields depends on the type of data. yadda
    > yadda. It's a big issue.
    >
    > Yet another reason I like passing disconnected recordsets back and forth
    > between client and server. They automatically contain enough metadata to

    let
    > you sort out what you need to do in cases of collisions. I remember

    writing
    > all that code in VB3 before ADO to manage all that stuff using BTRIEVE. It
    > wasn't terribly fun.
    >
    > I like ADO a lot more (though it's infuriating at times too!)
    >


    One solution, possibly over simplifying the issue, but one that worked very
    well for us sofar (and also one that was implemented by Software AG with a
    fair amount of success), was to add a so called "HoldField" field to every
    table that may be updated. I.e.
    User A Reads a record with HoldFld = 1
    User B Reads the same record, also with HoldFld = 1
    User B Saves the record with changes and updates the HoldFld value to 2
    User A attempts to save the record, but will be unable to do so, since his
    version of HoldFld differs from the one on the table and therefore implying
    a collision.....and yes, will bounce the conflict back to the client.
    Although I'm also a great fan of ADO, not all DB's are able to make use if
    it's benefits. The additional benefit of this approach is that we can now
    remain fairly independent of the implementation detail of the Datatier, i.e.
    using the same technology for various DB implementations, even including
    adabas, db2 etc.



  13. #28
    Jon C. Stonecash Guest

    Re: Best data transfer method

    In my view, the data access layer or a layer of the business logic
    that is "close" to the database has to understand the business rules
    that apply here. I do not believe that one can write a general
    purpose "one size fits all" class to handle anything that might come
    along. The conflict resolution logic has to have a deep understanding
    of the semantic meaning of what each of the fields that could be
    updated. The logic to handle a quantity field is must different from
    the logic to handle a status field which is in turn different from a
    descriptive field. My approach has been to handle as much as I could
    in the data access layer and kick problems back to the tiers closer to
    the user only when I had no way to resolve the issue.

    "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:

    ><Richard Dalton .> wrote in message <news:3a873416$1@news.devx.com>...
    >
    >> Hilmar, thanks for that. It's an interesting approach,
    >> bringing a recordset all the way to the UI as a read only
    >> view of the data, but doing updates through the object model.

    >
    >Just what is being passed through to the object model, though? I maybe
    >see a timestamp, so the data tier can catch most, though not all, update
    >collisions. Some collisions can slip through if you use SQL UPDATE to
    >write to the database instead of recordset objects, even if you're using
    >your own read-before-write checking, in this and similar scenarios:
    >
    >user a fetches record x
    >user b fetches record x
    >user a mashes his keyboard
    >user b mashes her keyboard
    >user a checks record x, sees no changes
    >user b checks record x, sees no changes
    >user a updates record x, hunky-dory so far
    >user b updates record x, nuking user a's changes
    >
    >I figure .Edit and .Update are using wheels I don't particularly want
    >to reinvent. And if the data tier detects a collision, what then? Do
    >we bounce it back to the user, or do we try to merge the changes? If
    >user A changed only field P and user B changed only field Q, can the
    >data tier figure it out, or does it have no choice but to choke? What
    >if both users change the same field, perhaps to the same value but
    >perhaps not, what then? What I'm doing now involves passing around
    >both the original data and the user's changes, won't let me separate
    >the business and data tiers, and looks rather like a job security
    >tier, all to avoid interrupting the data entry folks' work. =(
    >
    >"Grabbing my ankles so the end-users won't have to..."



    Jon C. Stonecash, Rainier Technology
    Internet: stonecash@cdev.com, Compuserve: 73014,1255

  14. #29
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Best data transfer method

    "Hilmar Retief" <hretief@hotmail.com> wrote in message <news:3a9afd65@news.devx.com>...

    > One solution, possibly over simplifying the issue, but one that worked very
    > well for us sofar (and also one that was implemented by Software AG with a
    > fair amount of success), was to add a so called "HoldField" field to every
    > table that may be updated. I.e.
    > User A Reads a record with HoldFld = 1
    > User B Reads the same record, also with HoldFld = 1
    > User B Saves the record with changes and updates the HoldFld value to 2
    > User A attempts to save the record, but will be unable to do so, since his
    > version of HoldFld differs from the one on the table and therefore implying
    > a collision.....and yes, will bounce the conflict back to the client.


    This is similar to SQL Server's TIMESTAMP field type. Whenever a record
    is modified, the timestamp changes. How does your method cope with both
    users writing their changes simultaneously, so that when each reads the
    HoldFld prior to incrementing it and writing the record, they both see
    HoldFld = 1? Heck, I'm not absolutely certain I've solved that problem!

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



  15. #30
    Hilmar Retief Guest

    Re: Best data transfer method

    > > One solution, possibly over simplifying the issue, but one that worked
    very
    > > well for us sofar (and also one that was implemented by Software AG with

    a
    > > fair amount of success), was to add a so called "HoldField" field to

    every
    > > table that may be updated. I.e.
    > > User A Reads a record with HoldFld = 1
    > > User B Reads the same record, also with HoldFld = 1
    > > User B Saves the record with changes and updates the HoldFld value to 2
    > > User A attempts to save the record, but will be unable to do so, since

    his
    > > version of HoldFld differs from the one on the table and therefore

    implying
    > > a collision.....and yes, will bounce the conflict back to the client.

    >
    > This is similar to SQL Server's TIMESTAMP field type. Whenever a record
    > is modified, the timestamp changes. How does your method cope with both
    > users writing their changes simultaneously, so that when each reads the
    > HoldFld prior to incrementing it and writing the record, they both see
    > HoldFld = 1? Heck, I'm not absolutely certain I've solved that problem!
    >


    Trying not expose my serious lack of expertise on DB mechanics , but
    here's how I understand it. With ADO (and SQL Server), after the process
    above succeeded, and the HoldFld's for the 2 users are the same and they are
    both doing the update at the same instant, ADO provides an "Optimistic Batch
    Locking" mechanism, which will only allow one update to occur and the second
    will be bounced back to the user. With say DB2 also being a 2-phase commit
    DB I guess the same applies to it's DBMS. Adabas(not 2-phase commit) is
    more interesting though. It relies heavily on it's built in language
    (Natural). It will only attempt to lock a record when the
    requesting(natural) program has both a "read" and an "update" statement in
    the same program construct.



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