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!
Last edited by izyrider; 11-23-05 at 14:29.
Reason: forgot to attach!
currently using SS 2008R2