On Tue, 22 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-21 17:11, Michael Van Canneyt het geskryf:
Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and
then all updates go through, unless the record was deleted.
Because they don't get notified about their data (last saved) being lost. :-)
Well, I prefer that over bugging our users with dialogs that they don't
understand
anyway. Additionally, it drastically degrades performance.
[getting a bit off-topic here]
That is a rather dangerous approach to take. Imagine two accountants have a
Clients transaction screen open - both adding new transactions. First
accountant processes a 1 million Euro purchase. Then the second accountant
processes a 50 Euro purchase. Using your thinking, that Client will now
only owe use 50 euros. :-(
Well, we actually have such an application (bookkeeping app).
And:
1. No the error will not occur, since they are processing different transactions
and therefor different 'documents'.
2. The balance is always calculated on-demand; not stored.
We handle concurrency slightly different. We use System Locks. The first
person in a area get the system lock. Anybody else afterwards only sees
that area as read-only with a option to send a message to the first user to
get out of that area if it is urgent.
We have a lock on the 'document' level. Only one person can edit a document
at a time. The second gets a message.
You can start documenting them if you wish. But they won't be included
in the official docs till fully finished.
That's what I asked, and I'm fine with that. :-)
(Actually, I started on fcl-json
to get it included on www.json.org. Documentation is a prerequisite)
I saw the message you forwarded from json.org - a reasonable prerequisite.
But with large consequences, given our time constraints :-)
I'm looking a bit more into JSON - it's a rather nice format. Easy to read
(human readable) and differentiates nicely between arrays, integer, object
and string types (describing data types) - much better than XML does.
eg:
<person name="john" age="28">
</person>
vs
{ "person": {
"name": "john",
"age": 28
}
}
The JSON output immediately tells me that name is a text field and age is
an integer field. It's not obvious in the XML where all attribute values
must be enclosed in quotes.
For small config needs, I think that JSON is a better choice. It's
leight-weight, which is also the very reason it was invented: to counter all
SOAP XML bloat.
Well, FPC makes using/handling json particularly easy. Even if I do say so
myself ;-)
A warning: FPC currently has only ansistring support for JSON. I didn't get
around to making it unicode-aware (as the standard actually dictates). But
with the new string type, this should be a no-brainer :-)
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
