InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 14:52:37 GMT20http://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxAnother way to keep the function using * up-to-date is :1. alter the table (which u r using in function)2. sp_helptext 'MyFunctionName'3. Copy the result4. Replace "Create Function" with "Alter Function"5. Run it and its ALL DONE!UPDATE: for view use followingsp_refreshview 'MyViewName'Wed, 07 Oct 2009 02:01:35 GMTM. Furqanhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxFor those lazy guys like me...You can create a SP that takes one varchar parameter that does all the lazy code generating work and with some extras like generating C# code to use as 'Parameters.Add(...' OR CRUD SP's for your solution.Just add the code generator SP to one of your Keyboard shortcuts (SQL2005/8: Tools/Options. Environment/Keyboard). Now you just highlight the table name in your query window and hit Ctrl+5 and it spits out the generated code for you. Then there is code generator SP's for your SP's for use in C# code too.You can do this with all the other popular sp_'s (sp_lock, sp_helptext, sp_who...)Here is a sample of a simple Select statement:[code="sql"]select case WHEN ca.mincol = c.colorder THEN 'SELECT [' ELSE ' [' END +c.[name] +case WHEN ca.maxcol = c.colorder THEN ']'+char(10)+'FROM ['+o.[name]+']' ELSE '],' ENDfrom syscolumns c join sysobjects o on c.id = o.idcross apply (select max(colorder) as maxcol, min(colorder) as mincol from syscolumns c2 where c2.id = o.id) as cawhere o.[name] = 'TableName'order by c.colorder[/code]If you want my code generator SP's just drop me a message. ;-)You can then modify it to your hearts content.Use it, don't use it. Up to you.LEON 'NO37'Wed, 16 Sep 2009 05:15:37 GMTNO37http://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxI agree that Ian's trick is totally cool.Actually, I'd like to comment on the original topic, using * in functions.Because of "pre-compilation", the function is remembering old info ratherthan using the current schema.The same effect may be found with views, also.All the same weird phenomena occur.To update a view with the new info, use exec sp_refreshview 'YourView'I wonder if the same medicine would fix your functions?Or if there is a corresponding proc for them.[I wrote this after I read the first page of comments, then I realized their were many more comments.]Tue, 15 Sep 2009 14:35:12 GMTThomas Considinehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Matt Whitfield (9/14/2009)[/b][hr]There are 1000s of really stupid things you can do in any programming language... that's what best practice is all about I guess. I think the only important thing is not to ram it down people's throats...[/quote]Absolutely.Mon, 14 Sep 2009 17:11:22 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Paul White (9/14/2009)[/b][hr]George, I do see your point, but remember that non-schema-bound views have always worked this way - it's not a special new thing. Metadata changes can affect non-schema-bound objects in unpredictable ways. It's difficult to see how SQL Server could sensibly be modified to change it either.[/quote]I think the key word here is 'sensibly' - sure you can use the ddl trigger style 'roughly sort it out' method - but honestly - even though I wrote it, I wouldn't use it... I just honestly can't agree that having *s bubble up is a generically sensible idea. And having thought a lot about it over the course of this thread, I have come to agree more with paul... There are 1000s of really stupid things you can do in any programming language... that's what best practice is all about I guess. I think the only important thing is not to ram it down people's throats...Mon, 14 Sep 2009 16:58:43 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]george.hames (9/14/2009)[/b][hr]I'm sorry if my example was too abstract, but it really doesn't matter. The point is that if the syntax is allowed it should work in a predictable manner, or it should fail at run-time. Unpredicable results are not acceptable in a grown-up database. The existence of work-arounds does not mean that there is not a problem, and documenting the unpredicability doesn't make it acceptable.[/quote]George, I do see your point, but remember that non-schema-bound views have always worked this way - it's not a special new thing. Metadata changes can affect non-schema-bound objects in unpredictable ways. It's difficult to see how SQL Server could sensibly be modified to change it either.Mon, 14 Sep 2009 16:43:30 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxI'm sorry if my example was too abstract, but it really doesn't matter. The point is that if the syntax is allowed it should work in a predictable manner, or it should fail at run-time. Unpredicable results are not acceptable in a grown-up database. The existence of work-arounds does not mean that there is not a problem, and documenting the unpredicability doesn't make it acceptable.gthMon, 14 Sep 2009 16:21:13 GMTgeorge.hameshttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]george.hames (9/14/2009)[/b][hr]If you can't think of a case where it is sensible to use SELECT *, then I suspect that your experience is rather narrow.[/quote]After EXISTS. That would be it. Please provide another example?[quote][b]george.hames (9/14/2009)[/b][hr]...there are times when you want to select ALL columns regardless of what they are. This would be particularly useful in a table function where you would not want to make any assumptions about what columns will be needed by applications referencing the function.[/quote]:blink: A multi-statement table function requires a definition, so you can't be talking about that. An in-line function behaves identically in a query plan regardless of whether you specify SELECT *, or a full column list. If you use star syntax, you cannot schema bind the function (error 1054). Unless you enjoy sudden changes in behaviour as discussed in the article, I don't see any advantage in using star syntax here. Or at all, really.[quote][b]george.hames (9/14/2009)[/b][hr]Documented or not, the behavior being discussed is not acceptable. As I said earlier, asterisk expansion in any given context must be either static or dynamic. It can't be half and half. Acceptable behaviors would be:[/quote]You forgot item 4) Learning to love column lists and schema binding[quote][b]george.hames (9/14/2009)[/b][hr]Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.[/quote]Item 4 again :-)Mon, 14 Sep 2009 15:41:50 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxSorry guys, my browser didn't display all the page numbers for some reason and i assumed there is only one page.My apologiesMon, 14 Sep 2009 14:53:07 GMTadjashttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]adjas (9/14/2009)[/b][hr]Any ideas?[/quote]Reading the thread? :-DMon, 14 Sep 2009 14:41:28 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxI might have missed something, but it occurs to me that the article still doesn't solve the problem of adding a column to a table by the software.You will need to know exactly what the column name is and when it is added. You usually don't, as the software was written by someone else and the source is not available.How does the function know when to include the new column. If you list all the fields the new one won't be included, if you list it and it's still not present you'll get an error.We might be able to use a DDL trigger in response to changing database schema (adding new column to a table). The trigger could alter the function in question. I am not sure if it forces the system tables to update. haven't had time to check it.Any ideas?Mon, 14 Sep 2009 14:29:11 GMTadjashttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]george.hames (9/14/2009)[/b][hr]Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.[/quote]Nope, it's not. But that's how it is... As for SELECT * - even if I want to return all columns to the user I still generally build something that does some meta-data inspection and returns a specific column set. For example, our website uses a data retrieval system that does three things:1) Gets the rows from a particular table2) Resolves any foreign keys in-line - bringing back descriptions from the foreign table based on the content of the referenced row in a configurable manner3) Checks for an ownership chain that can be validated (i.e. organisations are linked to purchases are linked to licenses, for example: the proc makes sure that if data is being retrieved on behalf of organisation x, then there is no chance that data can be retrieved that belongs to organisation y).However, the proc that does that makes views which are then schema bound into the database schema, which makes it really obvious when changing tables that you are going to influence other objects.I'm rambling. I need to sleep more. :-DMon, 14 Sep 2009 12:55:49 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxIf you can't think of a case where it is sensible to use SELECT *, then I suspect that your experience is rather narrow. As Alex pointed out, there are times when you want to select ALL columns regardless of what they are. This would be particularly useful in a table function where you would not want to make any assumptions about what columns will be needed by applications referencing the function. Documented or not, the behavior being discussed is not acceptable. As I said earlier, asterisk expansion in any given context must be either static or dynamic. It can't be half and half. Acceptable behaviors would be:1) The expression is expanded at compile time and continues return the same columns even if new columns are added.2) The expression is expanded at run time and returns whatever columns exist at that time.3) A run time exception is raised if the columns don't match the columns that existed at compile time.Any of these behaviors would be acceptable if documented. Returning bad data without raising an exception is not acceptable, ever.gthMon, 14 Sep 2009 11:27:55 GMTgeorge.hameshttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxI have run into this scenario using views in SQL 2000 as well. Does anyone know if this is also happens in later versions of SQL?Mon, 14 Sep 2009 10:02:10 GMTdlainehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]ben.mcintyre (9/14/2009)[/b][hr]D'oh, since most of my clients are still on 2000 ...[/quote]Doh. In 2000 sys.sql_dependencies is sysdepends - and it exhibits the same broken behaviour. But then on 2000 you're out of luck with both the Recursive CTE and the DDL trigger anyway! :-D[quote][b]ben.mcintyre (9/14/2009)[/b][hr]Seriously, thanks for the posts. You are a gentleman.[/quote]No worries, a pleasure.Mon, 14 Sep 2009 07:48:37 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Matt Whitfield (9/14/2009)[/b][hr]I'm not going to shove it down your throat because I get a bit over-whelmed by it all really - especially with coding - you post a simple question on a forum, and you get one person answering the question, and 15 others telling you that if you're asking that question then you've fundamentally misunderstood the universe.[/quote]Ah, that rarest of things, a non-judgemental forum poster ;-)[quote]One thing though - make sure that your client code doesn't retrieve columns from result sets using ordinals, otherwise bubbling up select *s can be entirely dangerous. [/quote]Please, don't even suggest that I use ordinals. Really ! Bleahhh, ooh I think I got got some on me ....[quote]Oh, and sys.sql_expression_dependencies is only in SS2008+. Under 2005 you have to use sys.sql_dependencies which isn't a reliable source of dependency information (i.e. it's easily broken).[/quote]D'oh, since most of my clients are still on 2000 ...Seriously, thanks for the posts. You are a gentleman.Mon, 14 Sep 2009 07:39:13 GMTben.mcintyrehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxWell, at the end of the day people can shove 'best practice' down your throat all day - but what matters at the end of the day is a working solution, and if that's how you go about it then fair play to you.I'm not going to shove it down your throat because I get a bit over-whelmed by it all really - especially with coding - you post a simple question on a forum, and you get one person answering the question, and 15 others telling you that if you're asking that question then you've fundamentally misunderstood the universe.One thing though - make sure that your client code doesn't retrieve columns from result sets using ordinals, otherwise bubbling up select *s can be entirely dangerous. Oh, and sys.sql_expression_dependencies is only in SS2008+. Under 2005 you have to use sys.sql_dependencies which isn't a reliable source of dependency information (i.e. it's easily broken).Mon, 14 Sep 2009 07:24:59 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxMatt - no I hadn't waded through all the pages, but I just did and have to say your little script is a keeper ! It makes my solution look like the ugly brute force hack it is. I hadn't plumbed the depths of the dependencies table before.More generally, my point is that SELECT * is a [i]feature[/i] with certain [i]risks [/i]associated with it. Like any feature, it can yield benefits as long as the risks are fully understood and managed.I know that SELECT * is almost universally regarded as bad practice, even as a coding error, but I simply don't agree that this is a blanket truth. * means 'all the columns in the table', and that in itself is not a bad thing.I think in team environments that the potential for confusion and unintended effects on other developers is much greater, and that this tips the balance, and is probably why it is regarded badly in the industry.For small teams, it can increase the agility of the code quite substantially. Add one column, and it can 'bubble up' through whole series of views to make itself available to the presentation layer without one single further keystroke. That's pretty powerful.While the idea of doing these refreshes is a bit ugly (much less so, thanks Matt), it's like a medicine. It doesn't taste good, but once you've swallowed it, it cures the disease and you've got a handy feature you didn't have before. It's a hack that doesn't pollute your actual code, it's a 'meta-hack' really.Mon, 14 Sep 2009 07:15:32 GMTben.mcintyrehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Paul White (9/14/2009)[/b][hr]P.S. Matt - OPTION MAXRECURSION (0) gives you 32767 levels IIRC[/quote]You are a goldmine sir.From MSDN: 'When 0 is specified, no limit is applied' - if you specify a number though it must be between 0 and 32767.To be honest though, the thought of seeing a schema which had a dependency tree 100 levels deep also fills my soul with BLACK [url]http://www.youtube.com/watch?v=QRJxafiqHvw[/url]Mon, 14 Sep 2009 07:09:25 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]ben.mcintyre (9/14/2009)[/b][hr]A warning: probably not for team environments.[/quote]You or the code? :blink:No, seriously, have you considered using the right-click on object, script as SELECT to...option in Management Studio?PaulP.S. Matt - OPTION MAXRECURSION (0) gives you 32767 levels IIRCMon, 14 Sep 2009 06:48:51 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxDid you see the DDL trigger I posted?You could add the guts of that instead of the 'refresh everything 7 times' with two distinct advantages:1) Everything would be refreshed once.2) There limit on nesting levels would be much higher (100 - the limit of a recursive CTE's nesting levels).I've got to say though, the thought of having to actually use that sort of code fills my soul with darkness...Mon, 14 Sep 2009 06:39:07 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxJust one note for the naysayers. This relates to the OP.I LIKE using SELECT *, since it allows full table data to be funnelled seamlessly up (along ?) through several levels of nested views without specifically mentioning columns. Sometimes, you do only want specific columns, but other times you really want everything in the table now and at any time in the future. BUT there is the problem described here, with views as well.Call it brute force, but since I have a program which keeps a database rev number and all the update scripts necessary to go from any rev up to the current rev, I simply put at the end of the update process a script which refreshes all views in the database using sp_refreshview (similar to this http://yellowduckguy.spaces.live.com/Blog/cns!DA380C13569E8907!336.entry).I run it about 7 times (to allow for nested views having SELECT * -yes all views in the db are refreshed 7 times, which is more than my maximum required nested view depth).Looks like you could refresh all the other (non-view) objects with sp_refreshsqlmodule.This refresh process takes a minute but it's part of a software uprgade process, so that time's not a big issue.In the dev environment, I'm onto it enough to remember to refresh views myself or call this global refresh if things get too messy.I still think it's much better than typing all those names(and re-typing them five times as they percolate up through the views). Saves a heap of time and verbiage. A line of code written is a line of code to be maintained. If done right, this technique is sexy.A warning: probably not for team environments.Mon, 14 Sep 2009 06:29:25 GMTben.mcintyrehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxAs a proof by authority, this is what Itzik Ben-Gan has to say about the EXISTS subquery:[quote]The use of * here is perfectly safe, even though in general it's not a good practice. The optimizer ignores the SELECT list specified in the subquery because EXISTS cares only about the existence of rows and not about any specific attributes.[/quote]("Inside Microsoft® SQL Server™ 2005 T-SQL Querying", Chapter 4)Mon, 14 Sep 2009 05:27:29 GMTAlex Fekkenhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Paul White (9/14/2009)[/b][hr]To be absolutely 100% clear on this: SQL Server contains code to recognize COUNT(*) and EXISTS (SELECT * constructs early on. No column meta data is ever accessed. COUNT(constant) and EXISTS (constant) behave identically in all cases, and without exception. There is not even the smallest benefit in using a constant. It may even work the other way around.Paul[/quote]Your avatar is *so* appropriate (and that's coming from someone who always thought the dark side should have won the whole star wars thing).Thanks for clearing it up :)Mon, 14 Sep 2009 05:16:15 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Rob Fisk (9/14/2009)[/b][hr]Surely using a constant can't be a negative though. I mean, COUNT(0) has the old school and William Gibson cool factor.[/quote]I will give you that. I'm just jealous because I am not 5% cool enough to use it (seriously, I'm not!)Your signature is awesome.@Alex: ROFL!Mon, 14 Sep 2009 05:10:30 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxPaul.It's good to know this and have it spelled out in the clear once and for all.Surely using a constant can't be a negative though. I mean, COUNT(0) has the old school and William Gibson cool factor.Mon, 14 Sep 2009 05:08:05 GMTRob Fiskhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote]you and I are going to fall out spectacularly if you use that 'colloquially' quip with Excel again!!![/quote]OK, OK. I was going to ask a question about the default font and colour of a column, but I forgot anyway. :cool:Mon, 14 Sep 2009 05:04:03 GMTAlex Fekkenhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxTo be absolutely 100% clear on this: SQL Server contains code to recognize COUNT(*) and EXISTS (SELECT * constructs early on. No column meta data is ever accessed. COUNT(constant) and EXISTS (constant) behave identically in all cases, and without exception. There is not even the smallest benefit in using a constant. It may even work the other way around.PaulMon, 14 Sep 2009 04:59:41 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxWill the '1 is more efficient than *' myth never die? It was briefly true for DB2 and Oracle (in different ways) but that was all a very, very, very long time ago.My personal favourites are:COUNT(1) - which the XML query plan shows as being implemented by a 'count_star' internal function; andEXISTS (SELECT NULL - which seems to be a sign of very muddled thinking...Latest research shows that COUNT(0) is even more efficient :laugh:COUNT(*) and EXISTS(SELECT * seem most logical to me, but it's not a religious thing. Use SQRT(PI()) if you must.PaulP.S. Alex - you and I are going to fall out spectacularly if you use that 'colloquially' quip with Excel again!!!Mon, 14 Sep 2009 04:44:22 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Rob Fisk (9/14/2009)[/b][hr]I changed your second query to use * rather than be identical to the first and the plans were still the same.[/quote]I think the difference would be in coming up with the plan, personally. Sure, it would be a *really* small difference - but I've always tried to engineer my DBs in such a way that it would scale as best as it could. A *really* small difference * x thousand transactions per second must add up...Mon, 14 Sep 2009 04:43:45 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxI would imagine select 1 would be marginally more efficient, because it doesn't then have to look at meta data in order to determine what * would actually be...Mon, 14 Sep 2009 04:40:47 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspxhmm, good point. I changed your second query to use * rather than be identical to the first and the plans were still the same.Perhaps older DBs did not optimise this out quite as well and that's where the methodology comes from?Mon, 14 Sep 2009 04:33:26 GMTRob Fiskhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote]Then there is no need to look up anyu columns or values from any columns at all you just get the literal. Much more efficient.[/quote]I am just guessing here but wouldn't SQL Server simply ignore the subquery's Select clause in this situation anyway? Still, I agree '1' is even easier to type than '*'.Mon, 14 Sep 2009 04:30:55 GMTAlex Fekkenhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Rob Fisk (9/14/2009)[/b][hr][quote]Specify the columns you need and schema bind where possible and appropriate. When requirements change, so does the code.I can't think of a case where it is sensible to use SELECT * in production code, except after EXISTS.[/quote]There is even less reason to use * in EXISTS I generally use EXISTS (SELECT 1 FROM...)Then there is no need to look up anyu columns or values from any columns at all you just get the literal. Much more efficient.[/quote]That's what I do too because I was told to do so many years ago, but I don't think there's a real performance gain in it.I think the exists subquery has no output list itself, but is always correlated to the outer main query. That's what I guess from the execution plan, but I could be wrong. Try and see for yourself:[code]-- SELECT 1 VERSIONselect *from syscolumns as awhere exists ( select 1 from syscolumns as b where a.id = b.colid) -- SELECT * VERSIONselect *from syscolumns as awhere exists ( select 1 from syscolumns as b where a.id = b.colid)[/code]The execution plans look quite the same...Mon, 14 Sep 2009 04:26:57 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Alex (9/14/2009)[/b][hr]I assume you would have hired him had he also mentioned the performance benefit of this approach? :laugh:[/quote]Oh, certainly! It was a close call... :-DMon, 14 Sep 2009 04:18:43 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote]Specify the columns you need and schema bind where possible and appropriate. When requirements change, so does the code.I can't think of a case where it is sensible to use SELECT * in production code, except after EXISTS.[/quote]There is even less reason to use * in EXISTS I generally use EXISTS (SELECT 1 FROM...)Then there is no need to look up anyu columns or values from any columns at all you just get the literal. Much more efficient.Mon, 14 Sep 2009 04:15:21 GMTRob Fiskhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote]Oh, and he said the best way to find the IDENTITY of a row after inserting it would be to truncate the table before inserting it, so that the IDENTITY would always be 1.[/quote]I assume you would have hired him had he also mentioned the performance benefit of this approach? :laugh:Mon, 14 Sep 2009 04:05:55 GMTAlex Fekkenhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Alex (9/14/2009)[/b][hr][quote]It is not like comparing MS Access with SQL Server or calling Excel a relational database (as one might 'colloquially'). :-)[/quote]Hahah - please don't make me spit out my coffee!! :-DI did interview a guy once who was trying his best to convince me that Excel was the best way to transfer data between two SQL Servers. When I asked him what a 'big database' meant to him, he replied that one with 1,000 rows or more was 'pretty huge'... Oh, and he said the best way to find the IDENTITY of a row after inserting it would be to truncate the table before inserting it, so that the IDENTITY would always be 1. I didn't want to even start on seed values :w00t:Mon, 14 Sep 2009 03:48:59 GMTMatt Whitfieldhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote]You must be joking, right?I wouldn't compare Firebird to SQL Server, way too many differences between them.I'm using both, and like both, but I would never use Firebird in place of SQL Server, exactly as I wouldn't use SQL Server in place of Firebird.[/quote]No I wasn't, actually. I agree that there are many differences but both are mature SQL-based client-server database engines, with SQL Server having a lot more extras beyond the engine if that's what you mean. It is not like comparing MS Access with SQL Server or calling Excel a relational database (as one might 'colloquially'). :-)Mon, 14 Sep 2009 03:35:48 GMTAlex Fekkenhttp://www.sqlservercentral.com/Forums/Topic492597-176-1.aspx[quote][b]Alex (9/13/2009)[/b][hr]Except for Firebird, which is free, and "broadly capable" enough for many applications[/quote]You must be joking, right?I wouldn't compare Firebird to SQL Server, way too many differences between them.I'm using both, and like both, but I would never use Firebird in place of SQL Server, exactly as I wouldn't use SQL Server in place of Firebird.Mon, 14 Sep 2009 01:26:48 GMTspaghettidba