text:
Let's deprecate UPDATE FROM!
I guess that many people using UPDATE … FROM on a daily basis do so without being aware that they are violating all SQL standards.
All versions of the ANSI SQL standard that I checked agree that an UPDATE statement has three clauses – the UPDATE clause, naming the table to be updated; the SET clause, specifying the columns to change and their new values; and the optional WHERE clause to filter the rows to be updated. No FROM or JOIN – if you need data from a different table, use a subquery in the SET clause. The optional FROM and JOIN clauses were added by Microsoft, as an extension to the standard syntax (and just to make out lives more interesting, they invented different variations of the syntax for SQL Server and for Access). So when you are in the habit of using them, be prepared to review all your UPDATE statements when moving to Oracle, DB2, Sybase, MySQL, or even a different Microsoft database!
Standards? Bah, who cares?
Well, some do. Me for instance – I will never use proprietary syntax if I know a standard alternative, expect if using the latter has severe negative consequences. And maybe you will, one day, when your boss comes back from the golf course with the great news that he managed to convince a colleague (who just happens to work in an Oracle shop) to buy a copy of your company's application instead of some off-the-shelf product. Or when there's a great job opportunity for someone with cross platform skills. Or when you are asked to help out this new colleague with 10+ years of DB2 experience. One of the lesser known side effects of Murphy's Law is that those who least expect having to move their database to another platform, will.
But even if you really don't care about portability, there are other reasons to be wary of using UPDATE FROM. In fact, the most important reason why I dislike UPDATE FROM is not that it's non-standard, but that it is just too easy to make mistakes with.
Correctness? Bah, who cares?
Well, most do. That's why we test.
If I mess up the join criteria in a SELECT query so that too many rows from the second table match, I'll see it as soon as I test, because I get more rows back then expected. If I mess up the subquery criteria in an ANSI standard UPDATE query in a similar way, I see it even sooner, because SQL Server will return an error if the subquery returns more than a single value. But with the proprietary UPDATE FROM syntax, I can mess up the join and never notice – SQL Server will happily update the same row over and over again if it matches more than one row in the joined table, with only the result of the last of those updates sticking. And there is no way of knowing which row that will be, since that depends in the query execution plan that happens to be chosen. A worst case scenario would be one where the execution plan just happens to result in the expected outcome during all tests on the single-processor development server – and then, after deployment to the four-way dual-core production server, our precious data suddenly hits the fan…
That's all?
Well, almost. There's one more thing. Probably not something you'll run into on a daily base, but good to know nonetheless. If the target of the update happens to be a view instead of a base table, and there is an INSTEAD OF UPDATE trigger defined for the view, the UPDATE will fail with this error message:
Msg 414, Level 16, State 1, Line 1
UPDATE is not allowed because the statement updates view "v1" which participates in a join and has an INSTEAD OF UPDATE trigger.
Of course, most people will never run into this. But I did have the misfortune of doing so once – unfortunately, I discovered this limitation after rewriting several hundred ANSI standard UPDATE statements to the equivalent UPDATE FROM, and having to convert them all back after as much as a single test…
And that's why you want to deprecate UPDATE FROM?
Well, no. The view with INSTEAD OF UPDATE trigger won't affect many people. And the possibility of error can be somewhat thwarted by making sure (and double-checking) to always include all columns of the primary key (or a unique constraint) of the source table. So we're back to the more principle point of avoiding proprietary syntax if there is an ANSI standard alternative with no or limited negative consequences. And in the case of UPDATE FROM, there are some cases where the standard syntax just doesn't cut it.
One such scenario is when a file is read in periodically with updated information that has to be pushed into the main table. The code below sets up a simplified example of this – a table Customers, with SSN as its primary key, that stores address and lots of other information, and a table Moved, which is the staging table containing the contents of a file received from a third party listing new address for people who recently moved. I have also included the code to preload the tables with some mocked up data – the Customers table has 10,000 rows, and the Moved table has 3,000 rows, 1,000 of which match an existing row in the Customers table. The others don't – those people are apparently not our customers.
CREATE TABLE Customers
(SSN char(9) NOT NULL,
Street varchar(40) NOT NULL,
HouseNo int NOT NULL,
City varchar(40) NOT NULL,
LotsOfOtherInfo char(250) NOT NULL DEFAULT ("),
CREATE TABLE Moved
(SSN char(9) NOT NULL,
Street varchar(40) NOT NULL,
HouseNo int NOT NULL,
City varchar(40) NOT NULL,
INSERT INTO Customers(SSN, Street, HouseNo, City)
SELECT RIGHT(Number+1000000000,9), 'Street ' + CAST(Number AS varchar(10)),
Number, 'City ' + CAST(Number AS varchar(10))
FROM dbo.Numbers
WHERE Number BETWEEN 1 AND 30000
AND Number % 3 = 0;
INSERT INTO Moved(SSN, Street, HouseNo, City)
SELECT RIGHT(Number+1000000000,9), 'New street ' + CAST(Number AS varchar(10)),
Number * 2, 'New city ' + CAST(Number AS varchar(10))
FROM dbo.Numbers
WHERE Number BETWEEN 1 AND 30000
AND Number % 10 = 0;
Since ANSI-standard SQL does not allow a join to be used in the UPDATE statement, we'll have to use subqueries to find the new information, and to find the rows that need to be updated, resulting in this query:
UPDATE Customers
SET Street = (SELECT Street
FROM Moved AS m
WHERE m.SSN = Customers.SSN),
HouseNo = (SELECT HouseNo
FROM Moved AS m
WHERE m.SSN = Customers.SSN),
City = (SELECT City
FROM Moved AS m
WHERE m.SSN = Customers.SSN)
FROM Moved AS m
WHERE m.SSN = Customers.SSN);
There's a lot of duplicated code in here. And if we were getting data from a complicated subquery instead of the table Moved, it would be even worse (though we can at least put all the duplicated code in a CTE since SQL Server 2005). Of course, writing the code is done quickly enough once you master the use of copy and paste, but the code has to be maintained as well.
Maybe even worse is that the performance of this query just sucks – if you run this (enclosed in a BEGIN TRAN / ROLLBACK TRAN, so you can run the variations below without having to rebuild the original data) and check out the execution plan, you'll see that the optimizer needs no less than five table scans (one for Customers, and four for Moved) and four merge join operators. And that, too, would be much worse if the source of the data had been a complex subquery (and no, using a CTE will not help the optimizer find a better plan – it just doesn't understand that the four subqueries are similar enough that they can be collapsed.
Now, if Microsoft had chosen to implement row-value constructors (as defined in the ANSI standard), we could have simplified this to
UPDATE Customers
SET (Street, HouseNo, City)
= (SELECT Street, HouseNo, City
FROM Moved AS m
WHERE m.SSN = Customers.SSN)
FROM Moved AS m
WHERE m.SSN = Customers.SSN);
But this is invalid syntax in any version of SQL Server (including the latest CTP for SQL Server 2008), and I know of no plans to change that before SQL Server 2008 RTMs.
But with using the proprietary UPDATE FROM syntax, we can simplify this, and get a much better performance to boot. Here's how the same update is written in non-portable code:
UPDATE c
SET Street = m.Street,
HouseNo = m.HouseNo,
City = m.City
FROM Customers AS c
INNER JOIN Moved AS m
ON m.SSN = c.SSN;
And now, the optimizer will produce a plan that scans each table only once and has only a single merge join operator. Some quick tests (with much more rows in the tables) show that it executes two to three times quicker than the ANSI standard version. For that performance gain, I will gladly choose the proprietary syntax over the standard!
What's with the title of this post then? Why deprecate a fine feature?
Patience, we're getting there. Bear with me.
All the above is true for versions of SQL Server up to SQL Server 2005. But SQL Server 2008 will change the playing field. It introduces a new statement, MERGE, that is specifically designed for situations where rows from a table source either have to be inserted into a destination table, or have to be used to update existing rows in the destination table. However, there is no law that prescribes that any MERGE should always actually include both an insert and an update clause – so with this new statement, we can now rewrite the above code as follows:
MERGE INTO Customers AS c
USING Moved AS m
ON m.SSN = c.SSN
SET Street = m.Street,
HouseNo = m.HouseNo,
City = m.City;
As you can see, the source table and the join criteria are included only once, just as in the proprietary UPDATE FROM. The execution plan (tested on the February CTP, also known as CTP6) is also quite similar, including just a few extra operators that are specific to the new MERGE statement. What really surprised me, was that the plan for the MERGE statement was estimated to be about 65% cheaper (faster) than the corresponding UPDATE FROM statement. However, I think SQL Server is lying here – a quick test with more data shows only an extremely marginal advantage of MERGE over UPDATE FROM. This test was too limited to draw serious conclusions, but I am quite sure that there will not be a 65% saving by using MERGE over UPDATE FROM. (I do expect such a saving form either MERGE or UPDATE FROM over the ANSI-compliant UPDATE statement for this case).
The good news is that:
1) The MERGE statement is described in SQL:2003 and can thus be considered ANSI standard. (In fact, SQL Server implements a superset of the ANSI standard MERGE syntax: everything described in the syntax is implemented, but there are some non-standard extensions that make the command even more useful as well. However, the example above uses only the standard features and should hence run on each DBMS that conforms to the SQL:2003 version of MERGE).
2) The MERGE statement will return an error message if I mess up my join criteria so that more than a single row from the source is matched:
Msg 8672, Level 16, State 1, Line 1
The MERGE statement attempted to UPDATE or DELETE the same row more than once. This happens when a target row matches more than one source row. A MERGE statement cannot UPDATE/DELETE the same row of the target table multiple times. Refine the ON clause to ensure a target row matches at most one source row, or use the GROUP BY clause to group the source rows.
3) The MERGE statement will gladly accept a view with an INSTEAD OF UPDATE trigger as the target of the update.
So as you see, MERGE allows me to achieve what I previously could achieve only with an ANSI standard UPDATE statement with lots of duplicated code and lousy performance, or with a UPDATE FROM statement that hinders portability, introduces a higher than normal risk of errors going unnoticed through QA right into the production database, and has some odd limitation on views with INSTEAD OF UPDATE triggers. None of these downsides and limitations apply to MERGE. And if there are any other problems with MERGE, I have yet to find them.
With this alternative available, I fail to see any reason why the proprietary UPDATE FROM syntax should be maintained. In my opinion, it can safely be marked as deprecated in SQL Server 2008. It should of course still work, as "normal" supported syntax in both SQL Server 2008 and the next version, and in at least one version more if the database is set to a lower compatibility – but it should be marked as deprecated, and it should eventually be removed from the product. Why waste resources on maintaining that functionality, when there is an alternative that is better in every conceivable way? I'd much rather see the SQL Server team spend their time and energy on more important stuff, such as full support for row-value constructors and full support for the OVER() clause. Or maybe even on releasing Service Pack 3 for SQL Server 2005!
55 Comments
You might as well ask them to deprecate their multi-row triggers:) Have you ever considered the update-from and multi-row trigger as different sides of the same coin?
Hi Steve,
Nice try, but it won't fly 🙂
My main reasons for suggesting to deprecate UPDATE FROM can be summarized in short as:
1) It's not part of the ANSI standard, nor (as far as I know) part of any other RDBMS;
2) Its results are undefined in some situations; and
3) There is (in SQL Server 2008) an alternative that does everything UPDATE FROM can and then some, without incurring the two previously mentioned problems.
Since you consider multi-row triggers a different side of the same coin, let's see how these three main points relate to them:
1) The ANSI standard describes both statement-level and row-level triggers. If no "FOR EACH [ROW | STATEMENT]" is specified, the trigger has to default to statement level – what you can a multi-row trigger. Granted, SQL Server does not exactly follow the ANSI standard syntax for triggers, but statement-level (multi-row) triggers are definitely ANNSI standard.
2) The results of multii-row triggers are defined very exactly, and in all situations. Whenever an insert, update, or delete is executed, the trigger will fire, with all rows affected in the "inserted" and "deleted" pseudo-tables. This is documented and described ad nauseam, and I've never seen anything unexpected happen WRT trigger execution.
3) One might argue that the ANSI standard still offers row-level triggers as a valid alternative for statement-level triggers. But since SQL Server does not implement them, there is (as of SQL Server 2008) no replacement for statement-level triggers. Deprecating them would leave us without any triggers at all! Definitely not a good idea.
After reading your blog post on this subject, I can only conclude that you are good at stringing together words that at first sight seem to make sense, but on second sight reveal your absolute lack of comprehension of the subject. Which is a shame, for I really believe that Dataphor deserves a better proponent.
Best, Hugo
Hi Alejandro,
Just to make sure you don't misunderstand me: I don't suggest deprecating UPDATE, it's only the FROM clause (and thus the possibility to join) in the UPDATE (and DELETE) statement that I'm targetting.
>UPDATE and MERGE, are part of the standard, aren't they?<<
Yes, they are – but the standard does not allow a FROM clause (or any other method of specifying a join) in the UPDATE statement.
>Let us know if you create an entry in connect.<<
I had not plannned to actually suggest this on Connect, but your comment made me change my mind. I filed https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=332437. I expect lots of negative feedback on this one! 😀
>I really like your writing style,<<
Thanks. That's good to hear.
Hey Hugo,
Nice post!
What about DELETE FROM (with JOINs)? Not as common as UPDATE FROM, but can also be replaced by MERGE.
As a side note, I agree that standards and sticking to them is important, but at least in 50% of the time it is more beneficial to a project that the code works in several versions of the same product than having the code work cross-platform. In these cases even if row-value constructors were introduced in 2008, I'd use UPDATE FROM in my code, for backwards compatibility.
S. Neumann
Hi Hugo,
Just to make sure you don't misunderstand me: I don't suggest deprecating
UPDATE, it's only the FROM clause (and thus the possibility to join) in the UPDATE > (and DELETE) statement that I'm targetting.
Thanks for the clarification. I did understand you, but made a mistake in my post and it was to late to fix it.
I remember from the request sent by Itzik Ben-Gan and Sujata Mehta, about the full support for the OVER clause, a section talking about "Vector expressions". In the document they suggest the implementation of "Vector expressions" to avoid declaring the same OVER clause in miltiple expressions. In the connect entry, the request changed to use the SQL:2003 WINDOW definition, which is more elegant regards OVER clause.
Thanks for creating the connect entry. You got my vote.
I hope Microsoft put more attention to the requests coming from the SQL Server community.
Hi Saggi,
Good catch!
I actually intended to include some comments on DELETE FROM, but when I noticed that I already was well over what I regard to be the maximum lengthh for a bllog post, I changed my mind. Forunately, you are now giving me a chance to make up for that.
DELETE FROM should never have been supported at all. I have never ever seen a query with DELETE FROM that could not have been written just as well with DELETE WHERE EXISTS. The only thing it has going for it is that its inclusion is congruent with the inclusion of UPDATE FROM — so when I suggest deprecating UPDATE FROM, it'll come as no surprise that I believe DELETE FROM should be removed as well.
By the way, the connect entry I opened after Alejandro suggested me to does in fact mention DELETE FROM as well.
Thanks, all, for your comments!
Hello Hugo,
"you are good at stringing together words…but reveal your absolute lack of
Well, you have a curious form of courtesy to those coming to your home:)
>"You might as well ask them to deprecate their multi-row triggers":)
"…there is (as of SQL Server 2008) no replacement for statement-level triggers. >Deprecating them would leave us without any triggers at all! Definitely not a good idea."
I confess to the mistake of again underestimating the amount of sarcasm needed to make a point (drip,drip:). Shouldn't you save such a precious commodity like scorn for a serious matter? I resent being called an empty suit for poking fun at sql:) Although I don't really see anything wrong with a connect candidate that argues for a redesigned trigger based on common sense considerations. Really, all I tried to do was bring attention to two constructs that share "multirow" considerations that don't make the lives of developers any easier. Both require an unwarranted intervention. To paraphrase you, an undefined update is "congruent" with a multirow considered trigger. As Hugo Igo, no?:) Speaking of standards, do you have two?:)
I'm quite sure we're talking about a moot point here as far as change. What would be interesting would be their "real" rationale. I wouldn't be surprised if it didn't include the usual suspects.
"…I really believe that Dataphor deserves a better proponent."
Now you're talking about a serious matter. I would gladly concede defeat in this battle to win a much wider war:) Can I finally compliment you for seeing the bright light? A relational form of update and a relational trigger are quite different beasts compared to their sql counterparts. We are talking about different considerations. I look forward to your taking up the challenge to lead sql folks to a relational system. And succeed where I have failed!
I tend to disagree about your ability to string together words. Steve, I found your blogs pretty hard to follow.
There's a lot to be said about working with the standards we have now. Steve, do you use a Dvorak or a QWERTY keyboard? Just because we may know that there's something better out there doesn't mean that we can or should dump what we have now, stop extending and polishing it, and start with what's "better". SQL is a lot like that. It may have cruft, but it's the lingua franca for data manipulation right now.
Hugo, I think UPDATE FROM should be deprecated when we have a standard syntax which performs as well and is as understandable as what we have now… But if they can't deprecate DELETE FROM, do you think there's ever going to be a chance that UPDATE FROM will be?
Hi Hugo,
I was unaware of the potential for undefined results. Data integrity is vital – enough for me to change my coding habits from Update From to Merge in SQL Server 2008. I'm sold on Merge based on your post.
Deprecating features has to be a tricky, touchy subject. There's stuff in SQL Server I'd like to see go, but it turns out I am accurately representative of precisely one user(s). I don't know how Microsoft decides on what stays and what goes. Based on history, I would guess ANSI compliance isn't at the top of the list.
:{> Andy
what do you think of the oracle syntax
update ( select …. from multiple tables )
set c1 = …, c2 = …
is this standard? safe? if so why doesn't sqlserver support it?
And using Merge isn't really an option for a lot of people since they have to support mssql2005 for probably at least another 2-3 years (and what about other vendor's dbms … not that you could use update from anyways…)
Wow, lots of new comments added. Thanks, all! I really appreciate it!
>you have a curious form of courtesy to those coming to your home:)<<
Hehe! The comments sections of my blog, especially after a deliberately provocative post, should be compared to a debating club, not to my home (though my home sometimes is hard to distinguish from a debating club).
As far as I'm concerned, everyone is free to speak their minds here – I have so far only removed comments that were pure spam (though I will also remove comments with high volumes of profanity). Yes, I can be harsh – if I think someone is wrong, I will say so in very clear words. And I expect no less from my readers when they see me making a mistake!
>Although I don't really see anything wrong with a connect candidate that argues for a redesigned trigger based on common sense considerations<<
So far, I've only seen you claim THAT SQL Server's triggers are badly designed, with insufficient backing. I've seen no proposed "common sense" replacements. But do let me know once you have the suggestion filed on Connect – I'll gladly read your suggestions, and if I agree that you have found a better way, I'll vote for it.
>Really, all I tried to do was bring attention to two constructs that share "multirow" considerations that don't make the lives of developers any easier. Both require an unwarranted intervention. To paraphrase you, an undefined update is "congruent" with a multirow considered trigger<<
Paraphrase? It looks more like an attempt to put words in my mouth. I don't see any congruence between the two.
UPDATE … FROM can cause a situation where two or more values are selected to be put into a single value – and there's no way of predicting which one will make it. That's why Books Online calls the behaviour UNDEFINED.
Triggers will fire once per statement, so that the trigger code has to be written just as set-based as all other SQL. Nothing unpredictable, nothing undefined – but for some programmers (a.o. those with Oracle background, where row-based triggers were for a long time the only option), this comes as a surprise. That's what the "consideration" in Books Online is all about – I'd personally rather call it a heads up or a warning.
The behaviour of triggers is correct and is defined in all situations, but some developers need a heads up. The behaviour of UPDATE FROM is undefined in some situations. You really can't compare those in any way.
re Dataphor – I won't be its proponent, sorry. It is a product I would like to get to know a bit better if I could spare some time – but I am currently trying very hard to squeeze 28 hours into each day, and it doesn't appear to be working. But I do hope that others, with more time available, will explore it – and I'm afraid that your anti-SQL crusade accomplishes rather the reverse – expecially when you use far-fetched arguments such as these. Come on, there are enough REAL problems in SQL Server, you don't have to clutch straws!
>But if they can't deprecate DELETE FROM, do you think there's ever going to be a chance that UPDATE FROM will be?<<
I was going to reply that I never really expected much from my suggestion on Connect, but I just got notice that a comment has been added on Connect – apparently, the SQL development team had already planned to look into the FROM clause for UPDATE and DELETE and will now take this suggestion as another consideration for the equation.
Ugh, that sentence didn't come out as intended. And it sounded so great when I heard it in my head (but that was in Dutch, unfortunately ;-))
Glad to hear that you have decided to shy away from UPDATE FROM in the future.
>I don't know how Microsoft decides on what stays and what goes. Based on history, I would guess ANSI compliance isn't at the top of the list.<<
I'd love to know, but I don't expect them to share. It seems as if there are multiple camps inside Microsoft, as you sometimes see new features that closely follow the standards (MERGE is a great example – the "extra" feratures are implemented in such a way that ANSI standard MERGE can be parsed and executed without any change), and then you see things going right against the standard (for instance, even though Books Online urges us to use ROWVERSION instead of TIMESTAMP for the ROWVERSION data type, the SQL generated from a table will actually use TIMESTAMP).
>what do you think of the oracle syntax (…) is this standard?<<
No. The late draft of the SQL:2003 standard that I have (check wikipedia for the download location, if you're interested) has this specification for UPDATE:
<update statement: searched> ::=
UPDATE <target table> [ [ AS ] <correlation name> ]
SET <set clause list>
[ WHERE <search condition> ]
Dunno. I've never had a chance to play with Oracle, and I was unaware of this syntax. But test for yourself – create two sample tables using the standard OrderHeader / OrderDetail scheme and then try to use this syntax to set a column in the OrderHeader table equal to one in the OrderDetail. This should fail (since you have to specifiy which of the different OrderDetail rows to use). If it works, it's just as unsafe as SQL Server's UPDATE FROM.
>if so why doesn't sqlserver support it?<<
I don't think they'll beat Oracle by copying its features. They have to try to stay ahead.
Anyway, since we've got MERGE now, there is no longer any reason to want them to copy this. Right?
>And using Merge isn't really an option for a lot of people since they have to support mssql2005 for probably at least another 2-3 years<<
That's why I suggested deprecating it first, and removing it after a couple of versions. So that people have ample time to fix their code.
Once more: thanks all for your great comments – do keep them coming!
I did a quick test (not using orderheader/orderdetail, just some schema I made up)
Updating the inline view fails with an error when the update isn't deterministic:
ORA-01779: cannot modify a column which maps to a non key-preserved table
I joined two tables t1 and t2 .. If I updated a column on t1 with a column on t2, I got the error unless the column I joined on was unique in t2 (I had to create a unique index .. the mere absence of duplicate values without a unique index still resulted in error) .. So the update of an inline view seems safe but nonstandard.
I checked the manuals and oracle does support update from. Using the join that generated the ORA-01779 error using the UPDATE ( view ) syntax, merge generates
ORA-30926: unable to get a stable set of rows in the source tables
When I added the unique index, merge performed as expected. I was able to test oracle 11.1 and 10.2, but I didn't have a 9.2 instance handy.
I did notice in comparing the oracle and sqlserver docs that sqlserver there is some variation in the supported syntax. They both support WHEN MATCHED, but sqlserver supports WHEN MATCHED AND, they both support WHEN NOT MATCHED but oracle doesn't support AND and TARGET can't be specified. SqlServer supports WHEN SOURCE NOT MATCHED that Oracle doesn't seem to support at all.
In any event, good blog entry — its got me thinking and made me reconsider merge over update from and double check what oracle supports (my company supports both sql and oracle) .. Once SQL2008 is the min platform, we should be able to use standard sql across both platforms instead of sqlserver's update from or the oracle's update of an inline view.
in the meantime, at the very least shouldn't sqlserver be generating an error if the update from isn't deterministic?
Hi Matt,
Thanks for testing on Oracle and sharing the results.
>I did notice in comparing the oracle and sqlserver docs that sqlserver there is some variation in the supported syntax<<
Correct. From what you write, it seems as if Oracle is supporting ANSI standard MERGE. SQL Server does so as well – but it has also added extra features and possibilities.
Fortunately, they have chosen the syntax so that the plain bog-standard ANSI syntax for MERGE is a subset of the full syntax, so any ANSI-compliant MERGE statement should work without change in SQL Server.
>in the meantime, at the very least shouldn't sqlserver be generating an error if the update from isn't deterministic?<<
I would prefer that to the current behaviour, but I don't think they'll change it – it would potentially break too much existing code. If they are prepared to do that, they might just as well pull the feature completely (and based on the comment on Connect, it appears as if they are indeed giving this serious consideration).
Best regards,
Dave Markle (and K's of others no doubt) said:
<quote> Just because we may know that there's something better out there doesn't mean that we can or should dump what we have now, stop extending and polishing it, and start with what's "better".<unquote>
To quote Dalton (Patrick Swayze) from 'Road House', "I get that alot". In case you haven't heard the Cloverfield of software is also offering an alternative, ie. the object model with LINQ/EFM. I assume you have the same sediment to MS:) Perhaps you don't like my way of courting you. I'm not bashing sql, I'm simply pointing out the holes in it and showing how the relational model fills them in. Is it irritating, probably so. There's always a price to be paid for examining a comfort zone. Of course MS has taken quite a different tack. You don't see MS evangelists getting into the face of sql folks do you. You don't see them directly addressing sql folks with the reasons why they should leave sql and work with an object model. Nope, they are more than content to leave sql folks alone. LINQ is really not targeted here because MS does not really care whether sql folks jump ship. You are expendable:) And they don't take the risk of getting your ire up and alienating you. It's quite an interesting strategy they have. Sql folks foster a product that is going in the opposite direction of their intentions without any opposition:)
Steve, I found your blogs pretty hard to follow.
Well the relational model is a 'real' theory. Dataphor is not trivial, you gotta use your head to think where you haven't had too in sql. No pain, no gain:) As the saying goes there is no such thing as a small logical difference. They are all monster differences.
Sql is "the lingua franca for data manipulation right now."
Yep, for a large variety of reasons amongst which an intellectual one is not among them. Users fear vendors but that's backwards. I'm hoping at some point the simple consent for sql as 'the' thing for data manipulation melts and coalesces around something else (just as MS does).
I found your blogs pretty hard to follow.
That's because you're used to the heavy lifting in BOL:) The "how" of syntax is easy, the "what" and "why" of it is not. The subject matter is not always obvious and to be entertaining at the same time is no easy feat. Go double or nothing, give me a second read:)
Hugo said:
As far as triggers go "…do let me know once you have the suggestion filed on Connect"
I think there's already too many users who are patronized. I'll stick with criticism:) The simplest common sense consideration for a trigger would be for the system to understand a 'row' as a type. As far as sql case closed:)
I'm afraid that your anti-SQL crusade accomplishes rather the reverse – expecially >when you use far-fetched arguments such as these.
Of the many arguments I've made against sql you're sentencing me on just this one? That hardly seems fair:)
Dataphor – I won't be its proponent, sorry. It is a product I would like to get to >know a bit better if I could spare some time…
Isn't that excuse on the same level as "I was just following orders"?:) Do you really want to leave pioneering work to others…like me?:)
Hi Steve,
>I'll stick with criticism:) <<
I expected as much. Criticising is easier than specifying an alternative.
>The simplest common sense consideration for a trigger would be for the system to understand a 'row' as a type.<<
Why? Coming from someone who claims SQL Server is not relational enough, this is a surprising statement. The relational model is about sets. SQL Server is (mostly) about sets as well.
Every serious SQL Server developer should learn to think set-based. And once you have mastered that, coding row-based triggers seems like a step backwards to me.
>Of the many arguments I've made against sql you're sentencing me on just this one? That hardly seems fair:) <<
I'm singling out this one, because this one happens to be made on my blog, as part of an attack of a view I presented.
On other places, I have learned to mostly ignore your posts.
>Isn't that excuse on the same level as "I was just following orders"?:)<<
No. "I was following orders" puts the blame on someone else. I take full responsibility for choosing to spend time on stuff I consider more important. That's my choice, and you're free to blame me for it. 🙂
>Do you really want to leave pioneering work to others…like me?:)<<
Yes. At least, this pioneering. I choose to spend my energy pioneering in different areas, where I think more progress can be made.
Best, Hugo
I use UPDATE FROM regularly. Result are AFAIK never undefined. Predictability of the statements are responsibility of developer. MERGE can replace it and do more, however, a lot of customers still use sql server2000/2005, so if they upgrade in a future to a version not supporting UPDATE FROM, I'd have to rewrite a lot of triggers and stored procedures working perfectly well.
If you know the data model well and how to properly join tables, you know how to write a predictable UPDATE FROM.
Do you blame a gun, when you shoot yourself in the foot? Usually not.
It should return an error in case of unpredictable result, but I'd never agree on removing this feature. The error would not break much existing code as I don't thing there are many misusing this. Also, bad UPDATE FROM sends trash to triggers.
About triggers. It would be nice, if we had BEFORE triggers:
if it rejects the update, no update takes place, if after trigger does it, the client must rollback the transaction. What if it's not a well behaving client? There are INSTEAD OF triggers, which can do the job, but they're not the same thing and have a lot of limitations.
it can modify data without performing an update (update the "inserted" table instead of actual table)
Into the same basket would go a request for row level triggers. Most of things can be done with statement level triggers, but sometimes a set based solution is not possible, so you have to use a cursor.
Updates that are deterministic!?! What an idea. I'm having a hard time convincing people that creating tables without a unique constraint is a bad idea. (OK, that's false. They agree that it is a good idea and maybe sometime in the future they may consider…)
I agree that deprecating "update from" in version 2010 (or whatever after SQL 2008) is a good idea but there are companies that run SQL 6.5 now. When would be a good time for commercial software suppliers to consider replacing with the "MERGE INTO" commands? Major companies are just now converting from SQL 2000 to SQL 2005 and they definitely aren't implementing sweeping changes in their code to take advantage of 2005 changes.
The only people who should consider using "MERGE INTO" now have control of their SQL driver and know it is not going to change into a non ANSI 2003 standard driver in the future. Hmm isn't that one of the reasons why we shouldn't use "UPDATE FROM"… we don't control our SQL driver?:)
Hello Hugo,
I expected as much. Criticising is easier than specifying an alternative.
When I said "I think there's already too many users who are patronized. I'll stick with criticism" I meant I would rather have someone criticize me for a point of view I expressed (like here) than be patronized based on a submission on Connect. And I thank you for reinforcing my decision:)
Lets look at the sql server big picture of the associations between Update, triggers and Match. In 'Multirow Considerations for DML Triggers'
"C. Storing a running total based on the type of insert"
Now if someone asks the question 'what is the optimal trigger to store a running total' the answer is the bedrock that sql rests on, 'it depends'. That's what a multirow consideration is, a dependency. There's no definition of a trigger independent of the data. And if nothing else this consideration results in more code than if the trigger was based on a row (ie for each row). More code runs contrary to the idea of parsimony of effort, where less is better. Now ask the simplest question of Update, "what can you update" and the sql answer is "it depends". It depends if it's an expression(no), a table(yes), a view with a single table (possibly), a view with multiple tables(no) etc. It's a relational idea that Update can be used with anything that the system recognizes as a table. Therefore there's no consistency to the sql Update. The motivation of Match is simply a way to overcome this inconsistency in sql. The idea of using Match to drive an insert or an update is something a relational system does implicitly. Sql cannot do the same because it requires an explicit concept of "keys" which is a different animal from sql indexes. But what is the price of Match? It too runs contrary to parsimony of effort.
This idea of parsimony is important. It's a central theme in MSs push for the object model (LINQ/EFM) and declarative programming. They are convinced that development can be done in a simpler way than sql. Perhaps this explains their patronizing on Connect:) I'm afraid MS no longer has their heart in sql. If I can only convince them that the relational model also is an example of "less is more":)
Hi Eirik,
Thanks for the history lesson. Even though I have actually worked with SQL Server 4.2 (which, IIRC, was still based on the common codebase), I never realised that UPDATE FROM existed back then. I always assumed that MS added it when they rewrote the entire codebase – but I never went the extra mile to actually check it.
Another general consideration is performance vs. portability. Various RDMS have their own flavours of SQL. So do you choose the lesser performing syntax in order to support ease of portability? Or do you code for each RDMS you choose to support with your application, but have optimised versions for each RDMS so that it performs the best it can for a given platform?
Rhetorical question, I'm not looking for an answer to it. It's six of one, half a dozen of the other. Or, as is more commonly heard in DBA circles, "it depends".
Nice article, good comments.
I guess, if the would deprecate update from, they would end up providing a "hotfix" with the need of a startup parameter to revert to the "old" behaviour. Cfr "views with order by" with the results actualy being ordered as defined in the view.
The new merge will have my favour.
Unfortunately, the subqueries you suggest require a tablescan for each. Lets say you are migrating data stored in a vision file format that you have to convert to line sequential format then import that data into a sql server db table. It's much easier and more efficient to use update from when dealing with 2 tables of 15 million records and 1 table of 7 million records to update from when they have character based key fields to combine that information in a relational format over 5 different tables. Perhaps you are correct with what you are saying but if no one pushes the envelope on standards then the implementations stagnate.
Your statement, "SQL Server will happily update the same row over and over again if it matches more than one row in the joined table, with only the result of the last of those updates sticking" is not true
SQL Server 2005 Books Online says, "a single UPDATE statement never updates the same row two times."
Thanks for your comment. You are right, insofar that indeed SQL Server will not physically update a row, write out the new value, then update it again. It will, however, read and process all matching rows in the source, changing the in-memory version of the "new" row on every iteration, before finallly writing out the final version.
The point I was making was not about performance (which it would have been if indeed each row was physically updated multiple times), but about unpredictable behaviour – since if the execution plan changes, so does the order in which rows are processed and hence the value that just happens to be "last".
If you copy the code below and paste it in SSMS, you'll see what I mean – just adding an index changes the effect of the UPDATE. (And if you run with "Include Actual Execution Plan" enabled, you'll also see that indeed all rows from the source table are read.
All others: Thanks for your comments as well!
Best, Hugo
CREATE TABLE Dest (KeyCol int PRIMARY KEY, DataCol varchar(20));CREATE TABLE Source (KeyCol int, — no PRIMARY KEY! DataCol varchar(20))INSERT INTO Dest (KeyCol, DataCol)VALUES (1, 'Original');INSERT INTO Source (KeyCol, DataCol)VALUES (1, 'First new value');INSERT INTO Source (KeyCol, DataCol)VALUES (1, 'Second new value');goUPDATE DestSET DataCol = s.DataColFROM Dest AS dINNER JOIN Source AS s ON s.KeyCol = d.KeyCol;SELECT *FROM Dest;goCREATE INDEX ix1 ON Source(KeyCol, DataCol DESC);goUPDATE DestSET DataCol = s.DataColFROM Dest AS dINNER JOIN Source AS s ON s.KeyCol = d.KeyCol;SELECT *FROM Dest;goDROP TABLE Dest, Source;
We use SQL Server, PostgreSQL and MySQL most of all the databases. All support some variant of UPDATE FROM. Granted its annoying they do it slightly differently. So UPDATE FROM even though not ANSI standard is not some weird thing concocted by Microsoft or Sybase.
It would be nice if all databases that support it do it the same way but I tend to find it more efficient and intuitive than any other way. I tend to like PostgreSQL implementation the most.
UPDATE sometable
FROM someothertable
WHERE sometable.someid = someothertable.someid;
There are also things such as Information_schemas – which are ANSI standard and supported by SQL Server, PostgreSQL, and MySQL (neither Oracle or IBM support those – so so much for standards)
One quick question. When updating multiple rows with multiple possible values using update-from statements, is it possible to have different values for each updated row?
Taking following scripts for example, is it possible to produce results like
1, 10
1, 20 ?
Or the results could just be one of
1, 10
1, 10
1, 20
1, 20 ?
I'd appreciate it if you can share your experience. Thank you.
USE tempdb;
IF OBJECT_ID ('dbo.Table1', 'U') IS NOT NULL
DROP TABLE dbo.Table1;
IF OBJECT_ID ('dbo.Table2', 'U') IS NOT NULL
DROP TABLE dbo.Table2;
CREATE TABLE dbo.Table1
(ColA int , ColB int);
CREATE TABLE dbo.Table2
(ColA int , ColB int);
INSERT INTO dbo.Table1 VALUES(1, 10);
INSERT INTO dbo.Table1 VALUES(1, 20);
INSERT INTO dbo.Table2 VALUES(1, 0);
INSERT INTO dbo.Table2 VALUES(1, 1);
UPDATE dbo.Table2
SET dbo.Table2.ColB = dbo.Table1.ColB
FROM dbo.Table2
INNER JOIN dbo.Table1
ON (dbo.Table2.ColA = dbo.Table1.ColA);
SELECT ColA, ColB
FROM dbo.Table2;
I learned a lot about UPDATE FROM by reading this! Thank you.
I reference it in a wiki discussion of UPDATE options in Oracle:
And I concur that MERGE is much more intuitive.
Just FYI
Here's a short URL for your entry: http://tinyurl.com/deprecateUPDATEfrom
Hi Alexander,
The link was hidden in one of the comments. Here it is again:
Best, Hugo
Hi Star,
Assuming you're using SQL Server and not any other database, I see no errors in the code you posted.
I suggest that you find a SQL Server forum or newsgroup and repeat the question there. And in order for others to help you find the problem, you best include table definitions (as CREATE TABLE statements) and some rows of sample data (as INSERT statements).
Good luck!
Some concerns with or disadvantages of MERGE:
Books online says that MERGE "may produce incorrect results" if a cte is used to filter out rows from the source or target, so in that case you do not end up with an assurance that there hasn't been a mistake.
To me, a lot harder on the eyes than UPDATE/DELETE FROM if all you are doing is updating/deleting. Also takes longer to write.
There are other caveats with filter criteria (besides cte warning, shouldn't be done in the ON clause), which leaves the WHEN MATCHED clauses, sometimes inelegant, or, adding derived tables with select & where clauses (or adding filters on the join clauses when no select). in contrast, update/delete from has a natural place for filter criteria, the traditional WHERE after FROM clause.
Of course merge is uniquely useful and powerful, & can do "upserts" etc., but that means it also has more subtle structure and considerations overall (e.g. merge is one of the few times that BOL mentions anti semijoins)–not a golden bullet that protects you from errors. the syntax and structure is new, more of a break from older syntax than one would guess at a quick glance.
One could simply add the same runtime error as MERGE has to UPDATE/DELETE FROM statements, with option to turn off or on (erland somm.'s suggestion).
Who said that any of the SQL Server 2008 new SQL stuff was any ANSI SQL Standard? MERGE INTO, please, since when is that 'standard'?
….. We've been coding on SQL Server 6.5 through 2008 R2 AND……Oracle 7.3 through XI using the SAME SQL CODE….. (we used to run the same code on Borland Interbase but that went the way of the DoDo bird…).
from 1996 – yesterday…..or is that today.
Don't even get me started on MINUS versus EXCEPTION…..
I guess I am late to the party once again.
Interesting article, thank you for the contribution, not sure that I agree with the logic of depracating UPDATE FROM using standards as a rationale, but intersting ang good article.
BTW the Merge clause in MySql does NOT provide the same functionality as the Merge clause in your argument. MySql merge is used to merge tables (go figure, aye?)
Kind Thanks.
What about "cloning" records from the same table?
Let's say we have a table "dbo.THING" like this:
1, 100
2, 200
3, Null –> This line could or could not exist.
([ID] is the Primary Key)
I have to copy values from ID 1 to ID 3. If id 3 exists, i have to UPDATE. If not, i have to INSERT.
It seems a perfect candidate for MERGE:
Declare @OldId int, @NewId int
Select @OldId = 1, @NewId = 3
Merge dbo.THING As Target
Using dbo.THING As Source
On (Source.[ID] = @OldId) And (Target.[ID] = @NewId)
When Matched Then
Update Set Target.[VALUE] = Source.[VALUE]
When Not Matched Then
Insert ([ID], [VALUE])
Values (@NewId, Source.[VALUE]);
But it doesn't work. It never matches even if a row with ID 3 exists, and gives me a Primary Key violation.
Or am I doing something wrong?
An "Update From" in this case would be straightforward.
Thank you
Nice replacement of UPDATE .. FROM by MERGE. But beware, SQL Server heavily extends the SQL:2003 / SQL:2008 standard MERGE clause. You might run into problems yet again, when you want to run your SQL on these databases taht support MERGE
Or on any other ones (including MySQL, Postgres), that don't support MERGE
Why is it not included in the "standard"?
I have grown up with SQL Server technology (since 2001) and I was not aware (and shocked to hear) that an update on joined tables was not defined in the SQL standards.
It probably means that if I need to update data in a table with values based on fields in other tables, that I need to use a subquery in the WHERE clause? That moves this discussion to the use of subqueries vs. joins. Probably with the same conclusion: the choice for subqueries or joins may depend on the specific data structure and data population of the database. Sometimes a subquery gives better performance, and sometimes a join does.
I definitely want to keep the choice for using either subqueries or joins. Yes, also in UPDATE statements. So I will definitely NOT follow SQL "standards".
Apart from that, I see no issues with NOT complying with SQL "standards".
During my entire career, I have NEVER encountered a single project with end-user requirements for supporting multiple DBMSes from the same business logic (except distributed heterogenous database layers, when two or more different DBMSes are used TOGETHER and have their own task for storing and serving SPECIFIC data). So I personally NEVER needed to strictly adhere to the SQL "standards".
So I am convinced that with real-life database application development, you will just need to write multiple DBMS-vendorspecific data layer functionality when you need to support different DBMSes. In each distinct data layer implementation, you will be able to use any standard or non-standard SQL commands to manipulate your data.
IMHO, this will simply stay this way until the SQL "standard" has matured enough (or until it has died a painful death). Just compare it with the development of HTML and CSS up to their current standard (HTML 5 and CSS 3)…
Cheers, and happy developing!


text:
Orion is a total conversion utilizing Valve Software's Orange Box engine. Orion immerses the player in an intense online experience with dynamic combat and a vast array of new features.. Featuring fast-paced tactical gameplay on futuristic battlefields, Orion brings the fun into gameplay.
Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.
Play With Devs - January 2011

subset: commoncrawl


text:
The reason that political science forecast models are reasonably effective at predicting the popular vote months in advance of the actual election is that they are based on the fundamentals that largely determine how people vote. As long-time readers will recall, these fundamentals typical include some combination of economic and foreign affairs indicators. These are short-hand measures – say, quarterly growth in disposable income and war casualties – that capture the state of the world, as viewed by Joe and Jane Six Pack. This does not mean, however, that candidates and campaigns are meaningless. Instead, our assumption is that both sides in an election will effectively focus on those aspects of the fundamentals that benefit their own candidate, and/or disadvantage the opposition. In other words, for the forecast models to work, each of the two major candidates must choose the best campaign frame, given the fundamentals.
Not surprisingly, given her previous experience on the national stage, Sarah Palin – in yet another "non-campaign" campaign stop in Iowa – articulated what I think will be the most effective Republican frame in 2012: ending "corporate crony capitalism" (unofficial speech transcript here). The phrase did not originate with her, but it was the takeaway line from her 45-minute address before mostly Tea Party activists yesterday. And it undoubtedly will work its way into the campaign frame of whoever wins the Republican nomination. (Here's the speech. In addition to the crony line [go to the 12:20 mark] her best line is: "You got off the couch, you came down from the deer stands, you came out of the duck blind, you got off your John Deere" to win an election victory of historic proportions in 2010 [this at the 9 minute mark]. That's America – either watching t.v. or shooting things! )
The reason why this campaign frame is so effective is that it is non-partisan; as Palin made clear yesterday, it can be used to bludgeon both Republicans and Democrats. By lumping in corporations with career politicians as "entrenched interests", this frame will attract independent voters who are disillusioned with the partisan polarization in Washington. Moreover, as a catchphrase it can be applied to a host of government policies, dating back to the original TARP (Troubled Asset Relief Program) passed by the Democratically-controlled Congress and signed into law by Republican President George W. Bush, through the auto bailout legislation, the $800 billion jobs stimulus bill and the Affordable Care Act, to name the most prominent. Think about the shorthand criticism each of these bills has received. TARP was viewed as a "bank bailout" that, in the end, did little to resuscitate the moribund housing market or to help those who can't meet mortgage payments. Rather than create jobs and lower unemployment, the stimulus bill funneled money to state and local governments and their political allies. Health "reform" as yet has done nothing to hold down skyrocketing medical costs, but it does force people to buy insurance, thus serving as a government-mandate that primarily benefits the health insurance industry. Never mind that the situation is more complicated than these shorthand descriptions suggest – there's no room for nuance in a presidential campaign. Campaign frames work when they encapsulate broadly held voter sentiment, and right now a sizeable chunk of the electorate views these programs through jaundiced eyes.
Palin's phrase is effective as a critique not just of policies, but of the legislative handmaidens as well. Consider who was instrumental in devising these policies and getting them through Congress. Why, the Wall Street bankers and financiers – Henry Paulson and Tim Geithner – and their academic cronies – Ben Bernanke and Larry Summers – who got us in this mess in the first place! Again, this is an unfair characterization of these individuals, but all's fair on the campaign trail. It's the traditional populist message that resonates with Americans' historic distrust of 'bigness" -big government and big corporations.
Note that these criticisms are precisely what fueled the Tea Party movement that proved so instrumental in returning control of the House to Republicans in 2010. But they also resonant with progressives who feel Obama and Democrats have been too willing to cut deals with Republicans to benefit corporate interests – see, for example, their reaction to the debt deal and the extension of the Bush tax cuts. That's why this campaign theme is going to prove so effective for whichever Republican emerges with the nomination. And it's a frame that Obama will need to counter if he is going to win a second term in the White House.
For her part, Palin continues running for president. Her Iowa speech was her most detailed to date, and in it she provided more than a glimpse of the "mavericky" campaign she will likely run. Her policy proposals include the elimination of "corporate welfare" in the form of tax loopholes and subsidies combined with an end to the corporate income tax – a clear effort to play both ends of the ideological spectrum against each other. It is unclear whether this latest effort will help begin to overcome the sizable negatives that are associated with her public profile, but national polls continue to place her among the top three Republican candidates, behind Perry and Romney. She goes to New Hampshire tomorrow.
Meanwhile, the President will provide the first glimpse of his likely campaign frame in a nationally-televised addressed this Thursday. I'll turn to that topic in my next post.


text:
Enamelwork, technique of decoration whereby metal objects or surfaces are given a vitreous glaze that is fused onto the surface by intense heat to create a brilliantly coloured decorative effect. It is an art form noted for its brilliant, glossy surface, which is hard and long-lasting.
Enamels have long been used to decorate the surface of metal objects, perhaps originally as a substitute for the more costly process of inlaying with precious or semiprecious stones but later as a decorative medium in their own right. Whereas paint on metal has a short life and, even when new, is overshadowed by the brilliance of the polished metal, enamelling gives the surface of metal a durable, coloured, decorative finish. With the painted enamels of the Renaissance and the portrait miniatures of the 17th century, the technique reached its most ambitious and artistic form, in which the craftsman attempted to create a version of an oil painting, using a metal sheet instead of a canvas and enamels instead of oil paints. This medium undoubtedly has its limitations—few painted-enamel plaques of the Renaissance, for example, are much more than one foot square—but while oil paints on canvas eventually fade and darken, the colours of enamels are permanent. Relatively few creative artists of distinction have chosen to work in this medium, however, and it has tended to be purely decorative.
Few types of metal objects have not, at some period, been enriched with enamelled decoration. Throughout history, jewelry has been made more colourful by the application of enamels. Similarly, arms and armour, horse trappings, and even domestic items, such as mirrors and hanging bowls, were embellished with enamel decoration. Throughout the Middle Ages, both secular and ecclesiastical objects, such as chalices, cups, reliquaries, caskets, crosiers (a staff carried by bishops and abbots as a symbol of office), and spoons, were elaborately enamelled. With the advent of painted enamels in the Renaissance, tableware was completely covered with enamel, and painted-enamel panels were used to decorate the ceilings and walls of rooms in the châteaus of France. Following upon the invention of the domestic table clock and of the watch in the 16th century, enamelling became one of the most popular forms of decoration for the dials and cases; by the 18th century, items of the drawing room, such as snuffboxes, etuis (cases for small articles like scissors and needles), tea caddies, candlesticks, scent bottles, and thimbles, were frequently made of enamel.
Among the objects decorated with enamels in East Asia are vases, incense vessels, teapots, suits of armour, and sliding doors.
Materials and techniques
Enamel is a comparatively soft glass, a compound of flint or sand, red lead, and soda or potash. These materials are melted together, producing an almost clear glass, with a slightly bluish or greenish tinge; this substance is known as flux or frit—or, in France, fondant. The degree of hardness of the flux depends on the proportions of the components in the mix. Enamels are termed hard when the temperature required to fuse them is very high; the harder the enamel is, the better it will withstand atmospheric agencies, which in soft enamels first produce a decomposition of the surface and ultimately cause the breakup of the whole enamel. Soft enamels require less heat to fire them and consequently are more convenient to use, but they do not wear so well, especially if subjected to friction.
Clear flux is the base from which coloured enamels are made, the colouring agent being a metallic oxide, which is introduced into the flux when the latter is in a molten state. The brilliance of an enamel depends on the perfect combination of its components and on maintaining an equal temperature throughout its fusion in the crucible. The colour of many enamels is achieved by a change in the proportion of the components of the flux rather than by a change in quantity of the oxide. For example, turquoise-blue enamel can be obtained from the black oxide of copper by using a comparatively high proportion of carbonate of soda; in the same way, a yellowish-green enamel can be obtained from the same black oxide by increasing the proportionate amount of red lead.
Clear flux is also used to make opaque enamels; the addition of calx, a mixture of tin and lead calcined, renders translucent enamels opaque. White enamel is produced by adding stannic and arsenious acids to the flux, the quantity of the acid affecting the density, or opacity, of the enamel.
The heated enamel, after being thoroughly stirred, is usually poured out onto a slab and allowed to solidify into cakes of approximately four to five inches (10 to 13 centimetres) in diameter. For use, each cake must be pulverized into a fine powder with a pestle and mortar; the powder then has to be subjected to a series of washings in distilled water until all the floury particles are removed. The metal, on which the powdered enamel is to be spread, is cleansed by immersion in acid and water. All trace of the acid is then removed by washing and by drying in warm oak sawdust. After the wet powder has been spread on the metal, it is allowed to dry in front of the furnace before it is carefully introduced into the muffle of the furnace (a compartment protected from the flame), where it is heated to the point at which it fuses and adheres to its metal base. The firing of enamel takes only a few minutes, and the object is then withdrawn and allowed to cool.
The various techniques practiced by craftsmen in the past differ mainly in the methods employed in preparing the metal to receive the powdered enamel.
In the cloisonné technique, thin strips of metal are bent and curved to follow the outline of a decorative pattern; they are then attached, usually soldered, to the surface of the metal object, forming miniature walls that meet and create little cells between them. Into these cells, the powdered enamel is laid and fused. After it has cooled, the surface can be polished to remove imperfections and to add to the brilliance. The cloisonné technique is particularly suited to objects made of gold, such as jewelry.
This process is the opposite of the cloisonné technique: instead of building up on the surface of the metal object, the surface is gouged away, creating troughs and channels separated by thin ridges of metal that form the outline of the design. The troughs are filled with powdered enamel and fused. The champlevé technique requires a thick metal base and therefore is used on copper and other base metals.
This technique is a sophisticated extension of the champlevé method, for again the metal surface has to be cut away and filled with enamel, but here there are two major differences. First, within the area that has been cut away to receive the enamel, a design or figural composition is chased (chiselled), or sometimes engraved, in low relief. Because the highest point of the relief is below the general surface of the surrounding metal, the enamel, which is level on its outer surface, lies in varying thicknesses over the modelled surfaces of the low relief. Second, because the coloured enamels used in this technique are translucent, the composition of the low relief shows through; and, since the metal used is normally gold or silver, the light is reflected back through the translucent enamelling, adding a brilliant tonal quality to the enamel, just as sunlight enhances the beauty of a stained-glass window. The effect of the reflected light varies according to the thickness of the enamel lying over the undulating surfaces of the low relief; consequently, an impression of plasticity and of three-dimensional modelling is created by the subtle variations in tonal strengths of the enamel colours, which range from bright highlights to the rich tones of the deep recesses.
The plique-à-jour technique is designed to produce an effect of a stained-glass window in miniature through the use of translucent enamels. The technique is exactly the same as cloisonné enamelling except that the strips of metal forming the cells are only temporarily attached—not soldered—to a metal base to which the enamel will not stick. After the enamel is fused and sufficiently annealed, the metal sheet, usually aluminum-bronze, is removed with a few light taps, leaving a network of metal strips filled with enamel "windows." The enamels can be carefully polished to enhance their appearance.
Encrusted enamelling (émail en ronde bosse)
Encrusted enamelling is the term used to describe the technique of enamelling the irregular surfaces of objects or figures in the round or in very high relief. Both opaque and translucent enamels are applied to these small-scale sculptural objects, which are usually made of gold. The great technical problem is to devise methods of supporting and protecting these objects during the firing. Frequently, plaster of paris is used to envelop parts of the object, leaving exposed only those parts on which enamel is to be applied and fused.
Painted enamels
This technique differs fundamentally from the preceding five in that the various coloured enamels are not separated from each other by metal strips or ridges. Although these enamels are still applied in their wet, powdered state, the adjacent patch of coloured enamel is first allowed to dry to avoid one running into the other and so blurring the outline between them.
The metal generally used in this technique is copper. It is cut with shears into a plate of the size required and slightly domed with a burnisher or hammer, after which it is cleaned with acid and water. The enamel is laid equally over the whole surface both back and front, and then the object is fired. The first coat of enamel being fixed, the design is delineated by drawing with a needle through a layer of wet white enamel or any other that is opaque and most advantageous for subsequent coloration.
In the case of grisaille enamels, the white is mixed with water, turpentine, spike oil of lavender, or essential oil of petroleum and painted over a dark enamel ground. Light areas of the design are painted thickly; gray areas, thinly to allow the dark ground to tone the white pigment. The technique creates a strong contrast between light and shade, creating an impression of low relief. The scenes in grisaille are sometimes rendered more subtly by hatching, executed with a pointed tool or needle to reveal the dark enamel beneath.
In coloured painted enamels, enamel colours are spread over the grisaille treatment; when fired, parts of the surface are heightened by touches of gold, usually painted in thin lines, like hatchings. Other parts can be made more brilliant by the use of foil, over which the transparent enamels are placed and then fired.
Ancient Western
The origins of the art of enamelling are uncertain. While there is archaeological evidence that glass was being made from the 3rd millennium bce in western Asia and from the 15th century bce glass vessels were undoubtedly being made in Egypt, there is no proof that enamelling on metal was practiced in either Asia Minor or Egypt until after the time of Alexander the Great (died 323 bce).
Perhaps the origins of the art are to be found on Mycenaean metalwork of the 13th to 11th centuries bce. Six gold rings, excavated from a Mycenaean tomb of the 13th century bce at Kouklia (near Old Paphos), in Cyprus, are decorated with a cloisonné technique that suggests an intermediary stage between inlay and true enamelling. Scientific examination has shown that the different coloured enamels were not in the form of powder when they were inserted into the cloisons before being fired and fused together; rather they were in the form of fragments of coloured glass. Unfortunately, no report exists of any scientific examination of a more accomplished example of Mycenaean enamelling—the decoration on the gold sceptre found in a royal tomb at Kourion Kaloriziki, in Cyprus—but it is generally believed that this is true enamelling and datable to the 11th century bce.
If true enamelling existed in Mycenaean work, it would be reasonable to expect the technique to have been inherited by the Greeks and transmitted by them to the rest of Europe, perhaps by way of the colonies on the north shore of the Black Sea and in the south of Italy. Unfortunately, however, there is a long gap between the Mycenaean enamels and the Greek gold jewelry of the 6th–3rd centuries bce, which is sparingly enamelled, often having no more than touches of blue and white enamel enclosed by thin gold wire openwork (filigree).
Until recently the most ancient examples of enamelling outside Mycenaean art were said to be on ornaments discovered in a cemetery in the Kuban, close to the Caucasus, variously dated between the 9th and 7th centuries bce; but the most important of these Kuban enamels, the famous Maikop belt buckle (the Hermitage, Leningrad) depicting a griffin attacking a horse, is now regarded by Russian experts as a forgery. Consequently, the earliest enamelling from south Russia may date from the 3rd or 2nd century bce.
A slightly earlier date is given to a number of excavated bronze objects of western European origin, which are said to bear the remains of cloisonné enamel decoration. Until this early Celtic material has been scientifically examined and proved to be true enamel as distinct from inlaid coral, cut stone (chiefly lapis), or coloured glass applied cold, theories about it remain open to question. At the present time it is a matter of conjecture what link, if any, may have existed between the enamellers in south Russia and those Celtic craftsmen who by the 3rd century bce, if not earlier, were using red enamel in place of coral inlay.
During the Roman period, enamelling—both cloisonné and champlevé on bronze—was carried on almost entirely in those old Celtic areas that had become the northern provinces of the Roman Empire. It may well be to these provincial works that a passage from the works of Philostratus, 2nd century ce, refers. The author, describing a boar hunt at which the riders appear with horse trappings ornamented in bright colours, writes:
It is said that the barbarians in the ocean [i.e., the Celtic tribes] pour these colours into bronze moulds, that the colours become as hard as stone, preserving the designs.
This is a fair description of the process of champlevé enamel and suggests that the technique, in use in the British Isles, was not practiced at the time in Greece or Italy. Enamelled horse trappings such as Philostratus describes have been found in many places in the British Isles. This type of Celtic enamelling of the Roman period lived on in northwest Europe, particularly in Ireland, until as late as the 12th century. Some of its more striking effects seem to be derived from Roman glassmaking practices, particularly its use of millefiori glass, a mosaic of very thin glass rods of different colours and shapes fused together and then cut into thin sections, which the Celtic craftsmen fused into a ground of coloured enamel.
The most dramatic development in the history of enamelling took place in the Byzantine Empire between the 6th and 12th centuries, a period during which only the cloisonné technique—almost exclusively executed on gold—was in use. At their zenith in the 10th–11th centuries, Byzantine enamellers created delicate, highly expressive miniature scenes in a great range of colours that shine like jewels. The masterpiece of this period is the altar screen "Pala d'Oro" in St. Mark's, Venice, believed to have been brought from Constantinople to Venice about 1105. The quality of Byzantine enamelling began to decline in the late 12th century.
There is no direct evidence that enamelling on metal was practiced at any Islamic centre in western Asia. Scholars who argue that the technique of Byzantine gold-cloisonné enamelling originated in Syria before the 7th century ce can point to just one object on inconclusive stylistic considerations, associated with Umayyad Syria. Only one other enamelled object has survived with strong Islamic connections: a dish with an Arabic inscription referring to an Artuqid Prince, who reigned 1114–44. The enamel technique is cloisonné, but with bronze wires soldered onto a copper base. As no other examples have been found and as the inscription in Arabic indicates an imperfect knowledge of the language, it may be the work of a Byzantine craftsman working in the Artuqid kingdom.
Western European
As early as the 7th century, according to some scholars, Byzantine work was being copied by Lombard craftsmen in northern Italy. Later it was imitated in Sicily and other parts of Italy—even perhaps in England, where the famous Alfred Jewel, made to the order of the English king Alfred the Great in the 9th century, shows strong Byzantine influence. In the Ottonian period (936–1002), gold-cloisonné enamelling seems to have flourished in eastern France, and in the Rhineland, particularly among the goldsmiths working at Essen and in the workshops 937–993) at Trier.
In western Europe cloisonné enamelling was abandoned in the 12th century, in favour of the champlevé technique executed on a base metal such as copper or bronze. This revival may have taken place first in Spain, in the valleys of the Rhine and the Meuse, or in France at Limoges; but, by the middle of the century, expert craftsmen in these centres—and in England—had established it as one of the foremost mediums for artistic expression in the Romanesque style. In the Mosan school, the famous 12th-century enamellers Godefroid de Claire at Liège and Nicholas of Verdun created champlevé enamelwork of unprecedented merit. The best work from Limoges was executed at the turn of the 12th–13th century; thereafter, the output was commercialized and standards fell steadily throughout the 13th and 14th centuries.
In the late 13th century, gold and silver objects were again decorated with enamel but in a new technique, basse-taille enamelling.The earliest surviving dated example was made in Italy in 1290. Throughout the following century, Italian goldsmiths, particularly from Siena and Florence, produced pictorial masterpieces in this medium. The technique was especially favoured in Spain and France. No more accomplished example has survived than the "Royal Gold Cup" (British Museum), commissioned by the brother of the French king Charles V about 1380. The sides and the cover have scenes depicting the life and martyrdom of St. Agnes in the most glowing rich colours and elegant draftsmanship of the period. The great era of basse-taille enamelling ended with the Renaissance, though it remained popular in Spain and southern Germany, chiefly in Augsburg, to the middle of the 17th century.
15th century to the present: European
Under the patronage of the courts of France and Burgundy in the late 14th and first half of the 15th centuries, goldsmiths devised new and more audacious methods of enamelling. Using translucent coloured enamels, they created the effect of stained-glass windows in miniature by the technique known as plique-à-jour. One of the loveliest pieces is the silver-gilt Merode beaker of Flemish or Burgundian origin, probably c. 1430–40, decorated with two bands of enamels set in tiny windows with Gothic tracery (Victoria and Albert Museum, London). Employing another technique, encrusted enamelling, they created both large-scale, three-dimensional compositions and miniature work to be worn as jewelry. Among the finest and earliest surviving examples is the Reliquary of the Holy Thorn (in the Waddesdon bequest in the British Museum): the Holy Thorn, set in a gem, is surrounded by the Last Judgment scene, in which all the figures (20) are enamelled, many of them being executed wholly in the round. The taste for this type of enamelled goldsmith work spread to all the courts of Europe; and, although the style changed several times, first from Gothic to Renaissance and then to Baroque, the essential extravagant toy-like quality remained. Of all the Renaissance goldsmiths who helped to create an international style, however, only Benvenuto Cellini wrote (c. 1560) a technical treatise on the subject.
Although the technique of painted enamels was probably first evolved by Flemish craftsmen about 1425–50 for the Burgundian court and perhaps developed by Venetian and north Italian enamellers between 1450 and 1500, the supremacy of the Limoges workshops was established by the beginning of the 16th century. For the next 100 years, French Mannerist art found talented expression in this medium, and, enjoying court patronage, the best Limoges enamellers strove to compete with other artists in decorating the rooms of royal palaces. Painting in grisaille was finally introduced at Limoges by about 1530–40.
A new dimension was given to painted enamelwork about 1620–30 by a French goldsmith, Jean I Toutin of Chateaudun, and some rival craftsmen in Blois. Their achievement was to invent a highly skillful method for fine miniature painting in enamel colours on a white-enamel ground. Since the technique was admirably suited to the current enthusiasm for portrait miniatures, artists of distinction, such as Jean Petitot, were employed by Charles I of England and the French kings to work in this medium.
With equal artistic skill, other French enamellers decorated items of jewelry, especially watchcases; and, by the second half of the 17th century, this craft had become centred on Geneva, where it continued to flourish into the 19th century. In England, particularly in the Midlands, the Continental style of painted enamelled "toys" was copied and produced on a large scale, but the technique of transfer printing on enamel was invented in England and brought to perfection at the Battersea (London) factory during 1753–56. The design was applied to the white-enamel ground by transferring to paper, and then to the surface to be decorated, an impression from an engraved metal plate that had been brushed with enamel colours. Throughout the 17th and 18th centuries, enamellers used the technique of fine miniature painting in enamels in Germany, Holland, England, and Russia in order to produce the "toys" of the fashionable world of society.
The technique called en résille sur verre flourished for only about 40 years (c. 1600–40), and few examples have survived. Yet it required an exceptional degree of skill. The technique consists of cutting the design in a medallion of glass, usually coloured, lining the incisions with gold and filling them with variously coloured enamels. The exponents of this kind of enamelling were mainly French.
Although surviving examples are rare, there is a distinctive group of brass objects, mainly candlesticks and andirons, which have green, blue, or white opaque enamelling. These objects were made in 17th-century England (perhaps in Sussex).
Most of the early enamelling techniques have continued to be used by goldsmiths in modern times—from the Parisian makers of gold snuffboxes in the 18th century to Carl Fabergé at the beginning of the 20th. Art Nouveau jewellers, such as René Lalique, and modern artists, such as Georges Braque, Georges Rouault, and Gerda Flockinger, have kept alive the craft of enamelling and added to the multiplicity of its ingenious effects.Hugh Tait
Enamels do not appear to have reached China until long after they were found throughout Europe. All authorities are agreed as to the Western origin of the art, which in all probability was introduced into China by traders or by travelling craftsmen. Although by the 5th century ce the Chinese were informed as to the production of glass—an essential material for the making of enamels—and were already highly skilled in the working of bronzes and other metals, there is no evidence that the art of enamelling was practiced before the Tang dynasty (618–907). There is in the Shōsō-in (principal storehouse) at Nara, Japan, a silver mirror the back of which is decorated in cloisonné. It is generally agreed that the mirror is of Chinese origin, dating from the Tang dynasty, as is certainly the case with many other objects in the collection. At present this is the only known Chinese enamelled ware made before the 14th century, but it can be safely assumed from this piece that the art of cloisonné was developed to a respectable height in the Tang dynasty. It appears that cloisonné work was well established in China at the end of the 14th century and that Byzantine work of similar character was also so well known as to invite comparison with the native product. The former may well have served as an example for Chinese craftsmen. As one scholar points out:
The workmanship presents occasionally…striking resemblances with certain enamels of the Byzantine school; the mixture of different enamels inside the wall of the same cell, the employment of gold incrustations in the treatment of the fingers and the hands, etc.
Active trade and cultural intercourse between the Near East and China during the Yuan (Mongol) dynasty must have been the reason for this revival of enamelwork, which then flourished through the Ming and Qing dynasties (1368–1644 and 1644–1911/12, respectively).
Chinese enamels fall into three categories—cloisonné, champlevé, and painted. In none does the technique vary appreciably from that employed in Western countries.
The earliest example of cloisonné enamel that can be authentically associated with east Asia is the silver mirror in the Shōsō-in mentioned above. Its cloisonné back is decorated in a design of a six-petalled blossom in three layers, the tips of the outer rows of petals forming 12 points of the mirror. The piece is regarded as a Tang dynasty work. Apart from this, the sequence of known Chinese enamels begins in the Yuan period, and the earliest recorded marks belong to the reign of the last emperor of that dynasty (1333–68). The great period of production is certainly that of the Ming dynasty, which followed.
The mark most commonly found within this period is that of the Jingtai reign (1449–57). The Ming enamels, bold in design with fine depth and purity of colour, were never surpassed in later epochs. The two shades of blue, a dark lapis-lazuli tone and a pale sky blue with a very slight tinge of green, are particularly excellent. The red is of dark coral tint, and the yellow is full-bodied and pure. Greens derived from copper are sparingly used. Black and white are the least successful, the former shallow and dull, the latter clouded and muddy. As fine as the Ming enamels are, however, there is an imperfection of technique, close examination revealing minute pitting in the enamels, which was caused by inadequate packing of the material, and some lack of polish in the surface. These technical defects, however, do not appreciably detract from the great artistic value of the Ming enamels.
A great revival of art industries took place under the patronage of the emperor Kangxi (1661–1722), who in 1680 established a series of imperial factories. He commissioned sets of incense vessels of cloisonné enamel for presentation to the numerous Buddhist temples founded under his auspices in the neighbourhood of Beijing, as well as other objects for the honorific gifts that were characteristic of his enlightened reign. The enamels produced during his time are marked by an improvement in technical quality as compared with those of the Ming period; to a considerable extent they also retained the finer qualities of the Ming wares. In many cases the forms of ancient bronze vessels were revived and enriched with enamels.
The style of this reign persisted during that of Kangxi's successor, Yangzheng (1722–35), while the long rule of Qianlong (1735–96) was marked, in enamel as in the case of many other industrial arts, by a further perfection of technique but by a loss of much of the vigour of design and breadth of execution that distinguished the products of earlier periods. Modern enamels, although they are primarily imitations of older work, are more hurriedly made and therefore not so well finished as the older work.
Some of the most ancient enamel examples extant belong to this class, and examples employing both champlevé and cloisonné are not uncommon.
Although the opaque enamels were more common, Chinese artisans occasionally used translucent enamels on a silver or gold base. The cloisonné back of the silver mirror in the Shōsō-in, for example, is decorated with transparent enamels, but important pieces such as this are rare. This technique more often appears in Chinese jewelry.
Painted enamels
The painted enamels of China are generally known as Canton enamels, from the principal seat of their manufacture—Guangzhou, which European traders called Canton. They are practically identical in technique with the Limoges and other painted enamels of Europe. Specimens of the latter are known to have been taken to China by the missionaries of the late 17th and 18th centuries; they not only exercised direct influence on the Chinese ware but also, in some cases, were copied. Representations of European subjects, copies of engravings and armorial decorations, are also found. Painted enamels are termed by the Chinese yangci ("foreign porcelain"), the palette of colours used being the same as with enamelled porcelain, whose decoration under foreign influence is called yangcai ("foreign colours"). A ground of opaque enamel, generally white, is laid on the copper, and on this the colours are superimposed and fired. The best period of this art was the 18th century. Although imitations have continued to be made, nothing of real quality in this style was produced after the termination of the reign of Qianlong in 1796. The method has always been looked upon by the Chinese as alien in taste; in fact, a great part of the Canton enamels were made for export, not only on European commission but also for clients in India, Persia, and several other Asian countries.
The art of enamelling in Japan may date back to the 7th century. One enamelled metal piece discovered in a tomb near Nara, probably from the 7th century, seems to be of Japanese origin. The civic Taihō code, compiled in the 8th century, provides one official to be in charge of founding metals and "painted glass decoration." Subsequently, however, this art seems almost to die out until the 17th century. When Dōnin Hirata I (1591–1646) made enamelled wares, having learned the technique from Koreans, his art was highly appreciated by Tokugawa Ieyasu, then the shogun of Japan, under whose patronage Hirata worked in Kyōto. There is a suit of armour with enamelled metal fittings ascribed to him, as well as enamelled metal fittings decorating sliding doors and lintels in the Katsura Palace, Kyōto. His family continued the trade until the late 19th century, making use, on a small scale, of both the cloisonné and champlevé methods. There was no further development of importance until Kaji Tsunekichi (1803–83) and his pupils established in Nagoya a successful manufacture of cloisonné, which obtained a considerable vogue, especially among foreigners.
While Kaji used brass cloisons and opaque enamel colours only, his successors used silver cloisons and succeeded in making both transparent and translucent enamels. They further modified the cloisonné process with remarkable ingenuity and produced work of great interest. First, they reproduced in minutely detailed cloisonné work realistic pictures, of trees and flowers, for example. This effort led them in the 1880s to produce lineless cloisonné enamels, which have all the beauty and brilliance of true cloisonné, with thick layers of enamel colours, but which, showing no trace of cloisons, permit a gradation of colours as in the less clear and brilliant painted enamels. The effect was achieved by taking off the cloisons before each firing, the process being repeated at least three times. The artists working for the factory of Namikawa Sōsuke of Tokyo in the late 19th century were most successful in this technique. Another Namikawa of Kyōto worked in true cloisonné. The factory of Jubei Ando of Nagoya has produced more variations. These developments have carried the art of enamel very far from the old traditions; while the skill and ingenuity of technique they evince may be appreciated, there is a danger of losing the artistry peculiar to the art of enamelling.The Editors of Encyclopaedia Britannica
Learn More in these related Britannica articles:
metalwork: EnamellingThere are two methods of applying enamel to metal: champlevé, in which hollows made in the metal are filled with enamel; and cloisonné, in which strips of metal are applied to the metal surface, forming cells, which are then filled with enamel. (For a…
interior design: ChinaEnameling on metal is an art that the Chinese learned from Europe, but, in the 18th century especially, some very large bronze vessels in a variety of ornamental forms were covered with enamel by utilizing the cloisonné technique. Painted enamels came from Guangdong (Canton) in…
metalwork: Gold and silver…India is famous for its enamels. Enamellers from Lahore were brought to Jaipur in the 16th century by Man Singh, and enamel was employed extensively in combination with goldwork and silverwork in the 17th and 18th centuries there and elsewhere. The Punjab, Lucknow, and parts of Gujarat state were long…
metallurgy: Barrier protection…layer of coloured glass called enamel. Enamel is inert and adheres tightly to the steel, thus protecting it from corrosion as well as providing an attractive appearance. Decorative chromium plating is another example of a protective-barrier coating on steel. Since chromium does not adhere well to steel, the steel is…
Pénicaud FamilyPénicaud Family, French enamelers active in Limoges during the 16th century, considered to be among the finest such craftsmen of their time. They were noted for their work in grisaille enamel, monochromatically painted enamel work intended to look like sculpture. Nardon Pénicaud (c. 1470–c. 1542),…
More About Enamelwork11 references found in Britannica articles
Assorted References
- application to metals
- use in Northern India
contribution by
- Godefroid de Claire
- Limosin
- Nicholas of Verdun
- Toutin
- In Toutin, Jean
use with
- Chinese interior design
- jewelry


text:
We have seen this play a thousand times. A fielder leaps into the stands and emerges miraculously with the ball in his glove. Did he actually catch it? Or did he sneak the ball into his glove after falling beyond the wall? We never know, and the umpires don't care.
But at least there is usually, you know, a ball in the glove.
Behold Replica Yankee Stadium and the Yankees versus the Indians. Jack Hannahan hits a flyball and Dewayne Wise goes into the stands and makes the grab. Or at least the umpire thought so.
Only one problem: Wise didn't even have the ball. And the umpire didn't even look for the ball.
Just watch ( via YES Network)...Your browser does not support iframes.


text:
Hi All. I just moved to Emeryville and am interested in playing tennis again. Would be awesome if I could get a game in today or tomorrow (8/20 or 8/21)
I am athletic and usually like to play hard enough to get a good work out. 3.0/3.5 level I would say.
Let me know.
Views: 339
Replies to This Discussion
Hi Mike,
Are you still looking for tennis partners? I'm a 3.5 player and can play weekends and some week nights. I'm in Berkeley and can travel a bit to meet you to play. Let me know if you're interested.
© 2019 Created by Mark / The Mayor. Powered by


text:
This "My Twinn (the just-like-me doll)" catalog was brought to my attention by my friend Lisa (she's an actual friend, not a doll). And after thumbing through it I felt obliged to reiterate a very important point to my readers: These kinds of dolls are deadly and should never, ever, be allowed into your home. They will roam your darkened hallways the second you close your eyes.
Trust me. Look at this doll and tell me that is not the face of evil.
Are there people on the planet who do not think these dolls are creepy? I bet you any money the nightwatchman at the My Twinn factory pays a therapist beaucoup dollars just so he doesn't go crazy from the nightmares and the pitter patters he hears in the warehouse.
Ways a My Twinn doll could kill you:
1. Deadly royal scepter. There can't be two queens in the kingdom kids. Little Polly here might not know it yet, but as soon as she climbs into her canopy bed tonight that scepter is going straight into her eyeball.
2. Suffocation. Little twinn Katie's wry little smile doesn't fool me one bit, she's got plans for when that bitch falls asleep.
3. Strangulation by garland. One of these monsters is bad enough, but get two in the same room and they will conspire together. These poor girls don't stand a chance.
4. Poison. You've all heard the toxic toy warnings, these little demons are MADE out of poison. All little twinn Lauren here has to do is let her hand steep in that tea for a minute, wait for big sister to drink, and bam, service for one please.
5. Neck Breaking and/or spinal cord injury. Don't be fooled by their supposed lack of dexterity. These dolls come highly trained. Think of them as evil miniature Charlie's Angels.
6. Mortal combat. Just walk away girls. Your dolls are not posing, they are getting ready to take you down.
This is just a horror movie waiting to happen. If you come home and see anything like this in your living room, GET THE FUCK OUT. These ladies mean business.
I hope you all heed this very important advice. One safety precaution to take if you already own one of these little bastards is to get a puppy. I mean the dolls are deadly, but they can only move so fast with a knawed off foot.


text:
The new Crary Big Top grain-hopper extension will increase the capacity of the Case IH 6088 and 7088 combine models by 75 bu. for a total of 390 bu. Crary manufactures the Big Top for combine models by Case IH, John Deere, New Holland and Gleaner. The Big Top features an easy-view grain-level window, rust-resistant panel length hinges, and heavy-duty construction. The Big Top ranges in price from $1,500 to $1,700.
For more information, contact Crary Co., Dept. FIN, 237 12th St. NW, West Fargo, ND 58078-0849, 800/247-7335, www.crary.com .


text:
The last few years have witnessed a great deal of economic instability, company upheaval and strategic refocusing. In the midst of these changes, outsourcing has continued to be a strong and beneficial outlet for fulfilling IT projects. To assist you along this path, we've pulled together a list of key points you should consider when approaching a new outsourcing project or rethinking a current contract
Top Outsourcing Trends for Q2 2010 The latest outsourcing trends identified by the Everest Group.
12 Hot New Tablets Hitting the Market The market is expanding at a brisk pace with many new competitive tablets being introduced to the public.
10 Reasons Why You Should Avoid Office Politics See why you're far better off avoiding office politics.
Related Topics : Database Migration, Infrastructure, Project Management, Request for Proposals, Strategic Planning
Chosen carefully, collaboration tools will save time, cut costs and reduce complications associated with storing and retrieving documents throughout a company's operations. ... More >>
Here are 10 highly rated project management apps from the Google Apps Marketplace that could provide you with the organization needed to successfully complete your next project. ... More >>
Here are a few of the key differences between hardware design and software development. ... More >>


text:
2. What are the minimum PC requirements to view the video?
Internet connection: wired connection at least 2Mbps;
Memory 4GB at least; Video Card: at least 2GB RAM with 512 bit for better viewing.
3. Can I view the video using my iPhone or iPad?
4. How do I make the video bigger?
5. Why is my video buffering?
6. I can't log in and get "Username Already Taken" message. What should I do?
7. How do I retrieve my password?
8. Can I transfer points from my SabongSports account to my accounts on your other sites or to other players' accounts?
9. What is the function of the RELOAD button?
NOTE: ALL TRANSACTIONS ARE STRICTLY VIA EMAIL ONLY. ANY LOADING, WITHDRAWAL, OR TRANSFER LOAD REQUESTS MADE THROUGH TEXT, FACEBOOK, SKYPE, OVER THE PHONE, ETC., WILL NOT BE PROCESSED. EMAIL US AT firstname.lastname@example.com. OUR CUSTOMER SATISFACTION OFFICERS (CSOs) ARE MORE THAN WILLING TO ASSIST YOU.
SabongSports.Com Group Management may effect changes and/or updates to its system and/or terms and conditions without prior notice. All rights reserved. ® 2013.


text:
We don't usually blog about movies, but wanted to recommend The Happy Movie (playing in San Francisco at the Roxie theater through the end of next week, free screening tomorrow night). We met Academy Award nominated director Roko Belic, who spent five years journeying around the world researching the question "what makes people happy?"
The movie looks in on people around the world (Calcutta, Okinawa, Lousiana, Bhutan, and more!), and demonstrates by example and through research that the people who are the happiest are not the people who are focused on external motivations (money, fame & social status), but rather internal motivations (relationships, community, helping others). The movie did an especially good job of highlighting how powerful it is to have a tight-knit family or group of friends.
It also points out that the happiest people are the highest functioning. In other words, make sure you're happy to make sure you're performing at your best.
Startup founders who are able to continue putting value on intrinsic motivations (relationships, community, and helping others) are more able to weather the fickle storms of fame and fortune, and remain happy throughout the process, regardless of whether their company somedays files for an IPO, closes its doors, or anywhere in between.
The movie is worth seeing; hope you like it, and would love to hear your thoughts!