Results 1 to 3 of 3
  1. #1
    Join Date
    May 2005
    Posts
    150

    Unanswered: Hey Izy.. you opened a can of worms...

    You said about not dealing with the bound world...

    because of the slowness that we experience I've been trying to map out a way of having the forms unbound. I just have a couple of questions...

    In the after update event of each control, do you save the record?
    - By save do you do an update SQL statement? If not how do you do it...

    Search forms...
    how do you create search forms?
    are they, dare I say, similar to the Access filter?

    Which is the "best" method of creating forms, bound or unbound?

    What are the benefits of using unbound forms?

    Do you experience the same delay when controls load?

    There are probably more questions I have but those are all that came off the top

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    sorry about the worms!

    where does your data live - JET or some sort of database server?
    i originally moved unbound to talk to MySQL and MSSQL after some initial disappointments with bound/linked MySQL tables.

    i don't know if there are good reasons for unbound with JET.
    the reasons i moved to unbound with xxSQL servers were:
    - running queries at the server
    - minimising network load
    - maximising concurrency
    and i don't think any of that applies to JET

    later i drifted in to doing standalone JET stuff unbound as well, but that was to simplify my life and not because i hoped for a performance gain.

    performance aside, there are good aspects to unbound - you get intimate control of your data. the downside is that you are forced to take intimate control of your data. almost nothing happens automatically so you have to code everything. if you have a job that pays per line of code - go unbound!

    Save: yes it's an UPDATE with so-called "optimistic concurrency locking": it's the lightest "lock" i know and i'm very pleased with it. i fill the edit screen from a one-record-recordset so after editing i have the old values (in the rst) and the new values (on the form). compare old & new and build SQL for the changed fields only. example for a single changed field:
    SET FieldA=NewValue WHERE ID=123 And FieldA=OldValue
    check records affected.
    1 - you are happy
    >1 - start looking for your backup
    0 - another user wrote after you read but before you wrote, so reload from the server and send a "sorry" msgbox to the user.

    using this no-lock lock means you need short edit sessions - a user who just filled in 100 textboxes will be peeved to be told that his edits were discarded. so i divide the editor into several screens (subforms switched in with .sourceobject) with just a few related fields on each screen in the hope that the user will edit and move on (_Unload triggers the save) before someone else attacks the same field in the same record. so that's another answer: i don't save each field after edit, but i also don't save entire records if the record is big enough to get split. saving each field after it is edited seems a bit of a burden, but i suppose it depends on the app and the likelyhood of two users hitting the same field/record concurrently.

    Search: i wouldn't recognise an A-filter if it bit me. my search uses SQL gathered from a form. there was a demo here before the site got trashed. i dug it out and attached it again. it's not a serious example, but it illustrates my way of doing it.

    Best: depends on your situation - can't say more than that.

    Delay: that's an interesting question. what is an acceptable delay?

    i have one app running in an instance on a MSSQL server 8000km from here. maybe there are 100 concurrent users on the machine of which 20...25 are on my app. an edit screen fills in +/- one second (varies a bit with LAN congestion) - i think that's acceptable. moving from 1 to 25 users when we went into production made no difference to response times, though the server probably got warmer.

    another example: a JET system with 2...5 concurrent users. it sits on a clean fileserver with a clean LAN and uses linked tables & mostly bound forms (this much-migrated but never re-coded Access-95 app is coming up for it's 9th birthday next month!). digging out a record to edit is suprisingly fast (still in the one or two second range), but running a mess of queries to build complicated reports is 20...30 seconds slow.

    if you are in JET i don't know of a clear-cut argument for unbound, and rather than rewriting a heap of code you may be better off seeing what you can do about the LAN & fileserver. JET (in my opinion) is never going to run well with many users and it's file-based nature is inherently fragile, but you can give it a better chance if it has a decent environment to breathe in.

    gosh that's a long reply - sorry!

    izy
    Attached Files Attached Files
    Last edited by izyrider; 11-23-05 at 14:29. Reason: forgot to attach!
    currently using SS 2008R2

  3. #3
    Join Date
    May 2005
    Posts
    150
    thanks for the reply

    I am going to start learning more about MSSQL and all that

    I've wanted to start from scratch on this project for months... now it gives me a reason Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •