none
Alter Table add Column - How do you add a column after say the second column

    Question

  •  

    When you use  "Alter Table add Column",  it adds the column to the end of the list of fields.

     

    How do you insert the new column to position number 2 for instance given that you may have more than 2 columns?

     

    Create table T1 ( a varchar(20), b varchar(20), c varchar(20))

     

    Alter table add column  x    varchar(20)  

    so that  the resulting table is

    T1 a varchar(20), x varchar(20), b varchar(20), c varchar(20)

     

    Can this be done programmatically?

     

     

     

     

     

     

     

    Wednesday, July 11, 2007 6:13 PM

Answers

  • Then you are quite 'wrong' with your 'guess'.

     

    Enterprise Managler most definitely

    • creates a new table with the column order you desire,
    • transfers all the data to the new table,
    • scripts out and adds the necessary constraints,
    • drops the old table,
    • and then renames the new table to the same name as the old table.

     

    As Umachandar indicated, Column order 'should' not matter.

    ALL Queries 'should' have a [ORDER BY] clause to control the presentation. AND ALL Queries 'should' have the desired columns listed instead of [ SELECT * ]. If that had been properly done in the original scripts and procedures, then nothing would 'break'. You are now 'suffering' the consequences of poor programming practices.

     

    To do anything else is just waiting for something to go wrong.

     

    If you 'must' have a certain column order, you MUST recreate the table. That can be an 'expensive' operation.

    Friday, August 24, 2007 5:02 PM
    Moderator

All replies

  • One option is to do the following (but it might take a while if you have lots of data):

    - insert all data in a temp table

    - drop the original table

    - create a table with the new column in place

    - insert all the data from the temp table in the new table

     

    Make sure you take into account all constraints, indexes, triggers, ...

     

     

    WesleyB

    Visit my SQL Server weblog @ http://dis4ea.blogspot.com

    Wednesday, July 11, 2007 7:08 PM
  • Order of columns is irrelevant in a table. You can retrieve columns in a specific order when you query the table. It doesn't have to be physically added in the same order and the internal row format also doesn't store it in the order you specified in the CREATE TABLE. So why do you care where the column is in the CREATE TABLE? What are you trying to do with that information?
    Wednesday, July 11, 2007 7:17 PM
  •     I was under the impression some SQL scripts would break.  Am I mistaken?

     

        insert into T1 select * from T2    ( I do run into these SQL scripts)

     

        ---------

     

        How does the Enterprise Manager insert a column into the table without having to drop the table and re-creating it?

       

        Thanks.

    Wednesday, July 11, 2007 10:39 PM
  •  

     

    If you alter either T1 or T2, then you need to address the query anyway.

     

    Enterprise manager copies the data out, recreates the table with the column in the position you designated, then copies the data back in....much as was described in an earlier post.

     

     

    Wednesday, July 11, 2007 11:42 PM
  • I was hoping that was able to run a script that would be able to add a column (let's say column in the second position)

    to both T1 and T2 so that I wouldn't have to searching for all the previous scripts that would break.

     

    When you do use a script to Alter a table the column is added to the end.   I end up having to go to the Enterprise Manager and drag and drop the column that is at the end of the table to the 2nd position. 

     

    I don't think the Enterprise Manager is recreating the table at this time.  It should be simply moving the pointers in syscolumns for instance.  I am just guessing, but that would be more` efficient.

     

     

    Friday, August 24, 2007 4:50 PM
  • Then you are quite 'wrong' with your 'guess'.

     

    Enterprise Managler most definitely

    • creates a new table with the column order you desire,
    • transfers all the data to the new table,
    • scripts out and adds the necessary constraints,
    • drops the old table,
    • and then renames the new table to the same name as the old table.

     

    As Umachandar indicated, Column order 'should' not matter.

    ALL Queries 'should' have a [ORDER BY] clause to control the presentation. AND ALL Queries 'should' have the desired columns listed instead of [ SELECT * ]. If that had been properly done in the original scripts and procedures, then nothing would 'break'. You are now 'suffering' the consequences of poor programming practices.

     

    To do anything else is just waiting for something to go wrong.

     

    If you 'must' have a certain column order, you MUST recreate the table. That can be an 'expensive' operation.

    Friday, August 24, 2007 5:02 PM
    Moderator
  •  Umachandar Jayachandran - MS wrote:
    Order of columns is irrelevant in a table. You can retrieve columns in a specific order when you query the table. It doesn't have to be physically added in the same order and the internal row format also doesn't store it in the order you specified in the CREATE TABLE. So why do you care where the column is in the CREATE TABLE? What are you trying to do with that information?


    In my case I care b/c I'm doing a view that is the union of all columns in 2 tables that should have the same columns in the same order but don't.  If the columns are in different orders, the union breaks.
    Tuesday, July 08, 2008 4:19 PM

  • I was also trying to do the same thing as Brad, adding a column to a table in a specific order.  I'm using SQL 2005 and the reason I need it as such is because I have a format file which specifies the order of the columns when inserting the data from a file off the 400.  Perhaps I should just live with new columns always being added to the end of the table, but I agree that it would be nice to be able to insert them in a certain order.  If nothing else, when I'm in Management Studio looking at a table, we have certain fields for auditing purposes that are in every table, and I like to see them as the last fields in the table.  Also, we have a few tables that are quite wide, about 30 rows, and it's nice to see relevant data grouped together.  For example, in the Item table, I'd like to see Department next to the Subdepartment field, the Location field by the Location Name and Location Code fields, etc. 
    Friday, July 11, 2008 7:00 PM
  • Brad,

     

    The UNION will only break if you are writing the queries the 'lazy' way and using [ SELECT * ].

     

    IF your queries were writting in a way that follows 'Best Practices', you would be itemizing the columnlist required, and nothing would 'Break'.

     

    Saturday, July 12, 2008 4:42 PM
    Moderator
  • To all concerned with adding a column to a table and having a specific column order:

     

    We recognize that while the SQL ANSI standard specifically indicated that column order is a issue that 'should' not be addressed except in the Query's columnlist, there is a 'move afoot' to offer the possibility with SQL Server.

     

    You may wish to visit this connect item and 'vote' on it -the 'squeakly wheel' theorem, etc...

     

    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124781

     

    Saturday, July 12, 2008 4:47 PM
    Moderator
  • This is definitely a needed feature, especially when designing databases with code generation - it can become very handy.

     

    Also - some newbies (I guess) conclude that the physical order has no meaning, but this is incorrect - in some cases you may need to expect specific columns not just by name - but by their order number and changing the order can break stuff pretty bad.

    Friday, December 05, 2008 12:16 PM
  • Can you provide an example of this. The only time I can think of this being an issue is through the use of SELECT *, which is just lazy programming that should never make it into a production environment.

     

    Friday, December 05, 2008 12:25 PM
    Answerer
  • About this issue, I already need the same, the ability to add a column some place in a middle of a table.

    I am not agree with the comment about column order is not a matter on programming, it is actually, my system has a window generator that takes fields from a specific table and builds the window and the order on which the columns are feeded into my code afects the results of some fields values, specially for those that are calculated from columns that are not readed yet.

    I saw the comment about if Manager can move a column easily it must be in the same way with alter table, but let me tell you when you move a column through Manager and save the changes it changes the table id and the columns order, so it is the same than creating a new table, copying records from current to the new table, droping old table and renaming the new one.
    Wednesday, March 04, 2009 5:18 PM
  • Your system requires it in a certain order, meaning that your system is programmed with the wrong mentality in mind. Column order has no meaning in a relational environment.

    If you need them in a given order, specify the order in your select statement.
    George
    Wednesday, March 04, 2009 5:40 PM
    Answerer
  • I haven't posted on this site before but was amazed at the replies when I came here to see if there was a keyword for MS SQL to do this. Sometimes even if all of YOUR code is clean, you do have to interface with dirty third party code that does things in "suboptimal" ways. Third party apps from small vendors are notorious for being written poorly, but are often purchased by people who do not have to support them. Luckily that's not my issue, but wildly saying "never use select *" isn't exactly a helpful answer when you're not talking to a complete noob.

    I was researching this very thing not for anything other than simple aesthetics - all of my production code explicitly retrieves columns, but when I'm previewing a table in SQL Studio, I really do want to see it in the correct order without having to drag all the fields into the query pane in the proper order. MySQL allowed you to specify order on ALTER TABLE a good dozen years ago if not longer, so it is surprising that MS SQL never seems to have adopted that ability.

    I'm really surprised seeing a lot of professionals just assuming they're talking to a noob and talking about "select *". Especially considering that this is something a freeware database has been able to do for a LONG time.

    Tuesday, May 04, 2010 8:11 PM
  • You might want to vote for this one, mentioned by Arnie Rowland a couple of years ago upstream in this discussion.

    https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124781&wa=wsignin1.0

    Current voting:  97 FOR, 10 AGAINST.

    RLF

    PS - I voted FOR, for what it is worth.

    Tuesday, May 04, 2010 8:25 PM
  • I voted. I have an impression I saw it before and may be even voted.
    Premature optimization is the root of all evil in programming. (c) by Donald Knuth

    Naomi Nosonovsky, Sr. Programmer-Analyst

    My blog
    • Proposed as answer by Semaqy Tuesday, May 04, 2010 8:47 PM
    Tuesday, May 04, 2010 8:30 PM
    Moderator
  • Its funny, I posted my ticket in March 2009 and I am just receiving answers on May 2010. Some issues from here:

    I migrated my application to MySQL so I haven't problems any more with defining an order on my tables.

    I didn't migratted to MySQL just for this topic, I got other benefits.

    I have few years experience in all topics on IT, not just and fully in programming and Design, I just would like to suggest don't be so square, using or not "Select *" doesn't mean or not that it is a poor way of programming; I am wondering how and why you can say it is a poor development or a poor application.

    You don't know the bottom line for this request!!!!

    Nothing is wrote, new technics in programming can rise and could need this feature or other "crazy" or "poor" requirement.

    Take in count that braking a paradigm looks crazy for many people, and it is to much probable that people will love your solution in the future.

    Have a nice day.

    Tuesday, May 04, 2010 9:01 PM
  • Hey Semaqy,

    Unfortunately you seem to have overlooked some of the key points raised in this thread.

    1) The order of data in a database has no meaning
    2) The order of columns in a database is meaningless
    3) Writing SELECT * is bad practice and poor forward planning

    The reasons for the above are as follows

    Order is determined by the question (query) you pose to the database. If your query states "give me all products where the the manufacturer is Microsoft" (i.e. SELECT product_name FROM products WHERE manufacturer = 'Microsoft') then it answers the question quite explicitly.
    If however you chose to extend your question, adding: "Oh, and I want them sorted alphabetically by product name", then you are actually asking a subtly different question, and your query needs to reflect this.
    Still don't believe me? Well then, let us extend the problem. Not only do I want the product name, I also want to include the product code now. Easy peasy (SELECT product_name, product_code FROM products WHERE manufacturer = 'Microsoft')
    In this query I have not included an ORDER BY clause, so what sorting should be applied? The answer is in the question: I haven't asked for the results in any order! So what does SQL Server do? Well, it just gives you the results in the quickest way possible (which is often the order of the clustered key, hence the common misconception of order in a database, but that is a discussion to be expanded upon later if required).

    So on we move to column order, but wait, isn't this just an extension of the ideology just discussed above?

    Last but by no means least: SELECT *...
    Now, it was wrong of me to be so blasé about never letting SELECT * in to production, because there are exceptions to every rule (and the exception that springs to mind here involves EXISTS).
    However, it is not incorrect to always treat the asterisk that way! The reason for this mentality is thus: imagine you have a nice, simple little table with 2 columns in it. You write your little SELECT * query and slap it in to your production environment and everything works just fine. A few months down the line your little table requires a minor change: a new field is required. What happens to that SELECT * that is now embedded in to your applications logic? Well, post-change, it starts throwing errors because the application is only expecting 2 columns and we're now supplying it a third. Don't forget, computers are stupid, they only know how to do what we tell them, and if what we tell them is that all it should get is 2 columns then that is all it knows.

    I hope that doesn't sound too ranty, it wasn't supposed to be, it was simply written in haste as the critical battery alarm has sounded on this little laptop and the charger is 20 miles away!


    George
    Tuesday, May 04, 2010 11:03 PM
    Answerer
  • You a quite correct that the order of columns does not matter in a REAL database but unfortunately Microsoft SQL is not a real database from that POV. The order of columns in the management console written above is one of the examples where order matters. Another is inserting data from an external CSV file. The below is my code to insert data but requires the columns in the database to be in the same order as in the CSV. I do not have control over the CSV order...

    BULK INSERT Connections
    FROM 'connections.csv'
    WITH
    (
    FIRSTROW = 2,
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '\n'
    );
    Monday, May 24, 2010 9:58 AM
  • I'd be interested to hear your opinion on what makes a database "real" and why Microsoft SQL Server does not fit the bill.

    As for your BULK INSERT problem: that's what a format file is for!

    linky: http://msdn.microsoft.com/en-us/library/ms191175.aspx


    George
    blog | twitter
    Monday, May 24, 2010 10:33 AM
    Answerer
  • From reading some comments i dont see one single answer , to me its a flaw that you cannot add a column after another column. This and other things are a little frustrating from MS|SQL, even if under the hood the db engine still drops the whole table and recreates it. 

    In reality, almost 100% of people interact with the DB from GUI and the column order can be beneficial in keeping some things in order. A really good point of the use of column order is the efficiency of the query results, say you have 3 id's : one primary key and 2 foreign. Besides the indexing, when the db is actually fetching the data from the disk, if between the ids you have say a varchar of 512 then the disk manager would have to go so very far blocks on disk to get just the 3 ids , when they are stored together they might be easier to fetch. Im not sure if this is what actually happens but it makes sense in theory, there is an order in the columns and there must be a reason behind it. does the db engine knows that id columns should be stored together ?  i dunno.

    Anyway i also dont buy the SELECT  * thing, why is it a bad practice ? it might be if you have 1000 columns and you only use 4, it all depends on the architecture, i have not seen a real example where you might get collateral damage from SELECT * unless people are fetching in ordinal orders (which to me is the actual problem).

    lastly can the blog people here fix the cursor display, im running firefox and it doesnt show a cursor in the editor...

    the question's answer is then: NO MS_SQL cannot add a new column after another column in one DDL statement.

    sucks if you have 40 GB worth of data in a table

    Wednesday, July 28, 2010 2:39 PM
  • From reading some comments i dont see one single answer , to me its a flaw that you cannot add a column after another column. This and other things are a little frustrating from MS|SQL, even if under the hood the db engine still drops the whole table and recreates it. 

    I agree that this is a missing feature. You can vote for it here
    https://connect.microsoft.com/SQLServer/feedback/details/124781/alter-table-syntax-for-changing-column-order

    Do you know of any major RDBMS that has this feature?

    In reality, almost 100% of people interact with the DB from GUI and the column order can be beneficial in keeping some things in order.

    Well, most users interact with the database from an application, in which case column order is immaterial. But, yes, when you are in support/debug situations "SELECT *" is very convenient, and having columns in a logical order is certainly helpful.

    A really good point of the use of column order is the efficiency of the query results, say you have 3 id's : one primary key and 2 foreign. Besides the indexing, when the db is actually fetching the data from the disk, if between the ids you have say a varchar of 512 then the disk manager would have to go so very far blocks on disk to get just the 3 ids , when they are stored together they might be easier to fetch.

    This on the other hand is completely bogus. The column order has no effect whatsoever on the efficiency of data retrieval. All data for a row is stored on the same page, and SQL Server reads data page by page. OK, so I lied a bit there, there are overflow pages, but all columns start on the same page. And besides, the column order on disk is not the column order you see. All variable-length columns come after all fixed-length columns.

    Anyway i also dont buy the SELECT  * thing, why is it a bad practice ?

    SELECT * is good when debugging and for ad hoc queries, but it has no place in production code. It makes traceability very difficult. Is the column foo in table bar actually used anywhere? With "SELECT *" you can tell that is referenced, but is it actually used? If foo is explicitly mentioned and the column is dropped by mistake, we will hurt ourselves fairly quickly. With SELECT * it may go unnoticed for a longer time, but the errors may be confusing.

    it might be if you have 1000 columns and you only use 4, it all depends on > the architecture,

    Well, the damage is big enough if the table has 8 columns and you need 7, but you don't need that far varchar(MAX) column.

    lastly can the blog people here fix the cursor display, im running firefox and it doesnt show a cursor in the editor...

    Then you need to find another place to remark about that. You don't really expect the webmasters for the forums to read every posts in all forums, do you?


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Links for SQL Server Books Online:
    SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
    SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
    SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
    Wednesday, July 28, 2010 3:23 PM
  • > Anyway i also dont buy the SELECT  * thing, why is it a bad practice ?
     
    So when you add a column to an existing table you are going to check all
    "SELECT *" queries to see if you don't need the new column in some of
    them? I don't expect you will. Instead, you will waste performance (and
    CPU cycles and memory) and give the optimizer fewer options for
    optimization.
     
    Now what happens if you add the column last_change_date, and you have an
    existing query that joins this table to another table that already has a
    last_change_date column? Then your "SELECT *" statement ends up with 2
    columns called last_change_date. Suppose your application depends on the
    existing last_change_date column, but now pick the "first" it encounters
    in the resultset, which happens to be the newly added! You will get all
    kinds of weird errors and possible database integrity problems as a
    consequence.
     
    If you happen to use "SELECT *" in a view, and you don't use
    sp_refreshview after adding a column to the table, then it gets really
    fun!  Especially if the view joins tables, and the column is added to
    the first table in the view. You should try it.
     
    So yes, using "SELECT *" in production code is a bad practice, and I
    consider it to be unprofessional. There is no reason (except laziness)
    not to explicitely name all individual columns that you need in the
    Selection List.
    --
    Gert-Jan
     
    Wednesday, July 28, 2010 9:31 PM
  • Hi Gert-Jan,

    To add, in SQL Server 2008 there's another reason to avoid SELECT *. If you have sparse columns and a column set defined in the table, by default SELECT * will return the XML representation of the sparse columns and not the relational one. Example:

    IF OBJECT_ID('dbo.T1', 'U') IS NOT NULL DROP TABLE dbo.T1;

     

    CREATE TABLE dbo.T1

    (

      keycol INT                   NOT NULL PRIMARY KEY,

      col1   VARCHAR(20)           NOT NULL,

      col2   INT            SPARSE     NULL,

      col3   CHAR(10)       SPARSE     NULL,

      col4   NUMERIC(12, 2) SPARSE     NULL,

      cs     XML column_set FOR ALL_SPARSE_COLUMNS

    );

    GO

     

    INSERT INTO dbo.T1(keycol, col1, col2) VALUES(1, 'a', 10);

    INSERT INTO dbo.T1(keycol, col1, col4) VALUES(2, 'b', 20.00);

     

    SELECT *

    FROM dbo.T1;

     

    keycol      col1                 cs

    ----------- -------------------- -----------------------

    1           a                    <col2>10</col2>

    2           b                    <col4>20.00</col4>

     

    SELECT keycol, col1, col2, col3, col4

    FROM dbo.T1;

     

    keycol      col1                 col2        col3       col4

    ----------- -------------------- ----------- ---------- ------

    1           a                    10          NULL       NULL

    2           b                    NULL        NULL       20.00

     

    Cheers


    -- BG
    Wednesday, July 28, 2010 11:23 PM
  • I guess you had enough disclaimers so I won't add one here. Just wanted to point out an alternative that may or may not be good enough for your needs, given the fact that SQL Server doesn't support natively adding a column in a certain ordinal position. You can rename the original table, then create a view with the original table name using the VIEW_METADATA option (ensuring that applications that ask for metadata get the view's not the underlying table's). Have the view specify the columns in the select list in the order that you need them. Then interact with the view instead of with the table. Example:

    -- original table

    create table dbo.t(a int, b int, c int);

     

    insert into dbo.t(a, b, c)

      values(10, 20, 30);

    go

     

    -- need to add column x after a

    begin tran

     

    alter table dbo.t add x int;

    go

    exec sp_rename 'dbo.t', 't_';

    go

    create view dbo.t with view_metadata

    as

     

    select a, x, b, c

    from dbo.t_;

    go

     

    commit tran

     

    select * from t;

     

    a           x           b           c

    ----------- ----------- ----------- -----------

    10          NULL        20          30

    Cheers


    -- BG
    Wednesday, July 28, 2010 11:51 PM
  • Itzik, I did not know that. I had never really thought about how sparse
    columns are implemented. But now that I know this "SELECT *" behavior, I
    know exactly how they are implemented!  This behavior is brutal!
     
    So in this thread is a nice collection of potentially terrible
    consequences of "SELECT *". I am definitely going to write a webpage
    that lists all these "accidents", with an example of each.
     
    When it comes to these sparse columns, and using your example, "SELECT
    *" could spell disaster if someone decided to add the existing column
    col1 to the list of sparse columns:
     
      ALTER TABLE dbo.T1
      ALTER COLUMN col1 VARCHAR(20) SPARSE NULL
     
    All of a sudden, the application using "SELECT *" will get a runtime
    error, because the column can no longer be found in the resultset...
     
    Thanks,
    Gert-Jan
     
    Thursday, July 29, 2010 10:28 PM
  • Your system requires it in a certain order, meaning that your system is programmed with the wrong mentality in mind. Column order has no meaning in a relational environment.

    If you need them in a given order, specify the order in your select statement.

    George


    I completely disagree. Column order isn't usually important and I rarely program with any necessary order in mind, but from a HUMAN standpoint, it's important that while looking at a table definition columns are ordered somewhat appropriately. Otherwise, why not name each with a couple of alphanumeric characters like a5 or something like that? What we are talking about is making a system that is easier for people not necessarily including programmers to browse. Here we have a very simple request for Microsoft, where Oracle and mySQL have had no problem, and due to either neglect or something I cannot comprehend, nothing has happened. It's not technically difficult to implement AFTER into the syntax.

    It's just silly this hasn't been implemented. What we're talking about is a minimal amount of effort here to save thousands of people a headache.

    Thursday, December 02, 2010 4:42 PM
  • I too came here looking to see if there was a quick Add Column After type trick and was amused (almost said amazed, but I've seen it too long to be amazed) at the depth of conviction of someone else telling me how to arrange things.  I never use Select * in a query, I generally always order fields in the order in which my brain thinks of them, and when I open a table to check it, my brain has a certain preference for the way things are set out.  As an example, I'm altering a couple of tables to add columns, and I prefer that the last couple of columns in my table are 'audit' type information about who and when.  If column order is completely unimportant, then why did the original programmers put the support in to allow you to insert a column wherever you like in EM? 

    Obviously, I voted for the change.  Perhaps the next vote will be for whether the arrogance meter should be capped at 8 on the you're really not that brilliant and I don't care what your absolutist positions are scale.

    • Proposed as answer by Vipresh Tuesday, February 28, 2012 10:02 AM
    Wednesday, December 15, 2010 11:47 PM
  • I agree with California.

    Whilst it's correct that the order of fields in a table is pretty much irrelavent, there is a good reason why people might group certain related fields together in the database structure. Good examples are first name, last name, or perhaps address1, address2, address3 etc.

    Image a table structure as follows:

    CREATE TABLE person

    (lastname char(64),

    dob         date,

    gender     char(1),

    upd_timestampt   timestamp,

    firstname  char(64))

    It works but doesn't sit right in my head.

    Clearly there is value in grouping fields together if for no other reason than it's aestetically pleasing and logical.

    Options are:

    1. create a backup table. Copy data to it. drop original. create new table with columns in the order you want. copy data back from the backup table (or some variation of this)
    1. add the column using ALTER TABLE. It will end up being placed at the end of the table. Then create a view that selects all the data in your table but with columns in the order that you want them. That way you can at least do stuff like SELECT * and get the data returned in the order you want. (I'm ignoring the pros/cons of SELECT * ). I believe you can also insert into views and update data in them though I've never tried this so am not aware of any pros/cons.

    And for those responses which talk about the order of columns being irrelavent. You guys need to come down from your ivory towers occasionally and live in the real world. Sometimes it's simply a case of a customer wanting a new field added to THEIR database table. Now you can waste time telling a customer that the position of a column in a table is irrelavent but if that's what they want and they're paying then that's what they should be able to get. Informix allows ALTER TABLE ADD COLUMN BEFORE COLUMN types of statements. Can't see why SQL Server and Oracle for that matter couldn't do something similar.

     

    Tuesday, January 25, 2011 9:42 AM