*Although this question references PHP, it is not actually PHP-specific, so I have not flagged it as such.*

We have a PHP framework which supports multiple DB back-ends.

There is a generic function in our data object class, which allows you to get records from the underlying table, with a specified criteria and sort order.

It looks something like this:

```
function GetAll($Criteria, $OrderBy = "") {

    ...

    // Add primary key (column 1) to end of order by list,
    // so that returned order is predictable.
    if ($OrderBy != "") {
        $OrderBy .= ", ";
    }
    $OrderBy .= "1";

    ...

    // Build and run query, returning the result as an array.
}

```

If you specify an `$OrderBy` argument of `StaffID` on a `Staff` object, the resulting SQL looks something like the following:

```
SELECT * FROM adminStaff ORDER BY StaffID, 1;

```

This works fine on a MySQL back-end, and from my searching of the web it should also be fine on most other DB back-ends. However, when using SQL Server, we get the following error message:

```
A column has been specified more than once in the order by list.
Columns in the order by list must be unique.

```

This arises because SQL Server disallows the same column appearing multiple times in the ORDER BY clause. In this case `StaffID` is column 1 and therefore we have multiple instances of the same column.

Is there a way to disable this check in SQL Server? MySQL provides a lot of options to enable/disable strictness checks and incompatible features - does SQL Server provide anything of that nature that would allow the above query to run without errors?

If not, do you have any suggestions for how we could resolve this in our data-object layer? Bear in mind we need to maintain compatibility with existing projects which expect this behaviour, so it is not sufficient to only include the first column when `$OrderBy` is blank.

The situation is also slightly complicated in the fact that the field list is customisable elsewhere in the data object configuration, so we can't rely on `*` being used as the field list - it could contain pretty much anything that is valid in a normal SQL field list. However, if that is asking too much, a solution to the simpler case (as outlined above) would be a good start!