parametr w zapytaniu - mssql

Witajcie.
Piszę własny mechanizm obsługi bazy danych,
Mam metodę wykonującą select:

        public override DataTable ExecuteSelectSQL(string cmd, params object[] param)
        {
            SqlCommand sqlCommand = CreateSqlCommand(cmd);

            int index = 0;
            foreach( object obj in param )
            {
                index++;
                sqlCommand.Parameters.AddWithValue("P" + index, obj);
            }

            return FillTable(sqlCommand);
        }

Niestety owy kod nie działa, gdyż nazwa parametru (np. P1, P2 itd.)
nie jest adekwatna do tego co faktycznie programista chce wyszukać (np. select * from users where id = @id)

Mój mechanizm ma być uniwersalny, dlatego czy można to obejść, by nie trzeba było podawać faktycznych nazw parametrów dodając parametr?
Oczywiście jednym z rozwiązań jest zamiana parametrów wejściowych w metodzie na tablicę objectów, a potem taka sama tablica z nazwami pól, ale chciałbym tego uniknąć.

Pozdrawiam.

Pobierać ze stringa gdzie jest komenda SQL nazwy parametrów, wyszukiwać odpowiednie stringi, które zaczynają się na @. Wsadzić te nazwy parametrów (z @) do tablicy stringów i odpowiednio wykorzystywać w pętli. Jednakże dla wygodnego korzystania z bazą danych zamiast ADO.NET polecam ORM np. Entity Framework lub NHibernate (i by programować jak człowiek to bibliotekę FluentNHibernate).

Świetny Terrorysta napisał(a):

Niestety owy kod nie działa, gdyż nazwa parametru (np. P1, P2 itd.)

ÓW, nie owy.

Mój mechanizm ma być uniwersalny, dlatego czy można to obejść, by nie trzeba było podawać faktycznych nazw parametrów dodając parametr?

Chcesz powiązać parametr zapytania z jakąś wartością, nie używając jego nazwy? Czyli jak inaczej, losowo?

Po prostu musisz inteligentniej budować zapytania, np. przekazać kolekcję wyrażeń lambda, z których zbierzesz nazwy pól do klauzuli where oraz wartości na potrzeby zapytania. Tylko trzeba pamiętać, że pola klas mogą się nazywać inaczej niż kolumny w bazie, co jest dodatkową komplikacją w tym przypadku.

A najlepszym rozwiązaniem zazwyczaj jest nie wynajdowanie koła na nowo. Naprawdę istniejące ORMy Ci nie wystarczają?

ÓW, nie owy.

Wow. Dzięki nie wiedziałem o tym. Sprawdziłem i faktycznie masz rację :)

Chcesz powiązać parametr zapytania z jakąś wartością, nie używając jego nazwy? Czyli jak inaczej, losowo?

Parametry masz w odpowiedniej kolejności. Nie trzeba podawać, więc nazwy wystarczy podać zgodnie z kolejnością, a nazwy opcjonalnie.
Tak np. można zrobić w Oracle i MySql, ale MsSql jest dziwny i na to nie pozwala.

Ja sobie z tym poradzę ogólnie, ale ciekawi mnie czy MsSql faktycznie nie pozwala na konstrukcję:
SELECT * FROM users where id = ? and name = ?

Co do ORM to projekt ów ( :) ) jest moją ciekawostką pisaną dla funu - ma być to ORM. Korzystanie, więc z ORM-ów jest słabe nieco :)
Aktualnie robię moduł odpowiedzialny za połączenia do baz danych, a potem framework tłumaczący kod w C# na zapytania bazodanowe.

Kiedyś pisałem już własny framework do testów jednostkowych sprawdzając, czy da się to napisac inaczej niż jest to zrobione w NUnit.
Ot taka robota dla zabawy.

Świetny Terrorysta napisał(a):

Tak np. można zrobić w Oracle i MySql, ale MsSql jest dziwny i na to nie pozwala.

Dziwne to jest używanie foreach z zewnętrznym indekserem zamiast po prostu for. :)

Ja sobie z tym poradzę ogólnie, ale ciekawi mnie czy MsSql faktycznie nie pozwala na konstrukcję:
SELECT * FROM users where id = ? and name = ?

O ile mi wiadomo, to nie. A przynajmniej nie da się takiego zapytania użyć w ADO.NET dla MSSQL.

Aktualnie robię moduł odpowiedzialny za połączenia do baz danych, a potem framework tłumaczący kod w C# na zapytania bazodanowe.

Nazywanie kilku klas frameworkiem to też przesada. :)

Proponowałbym użyć LINQa. Nie jest jest to wprawdzie EF, ale ADO.NET z punktu widzenia programisty baz danych w c# to już trochę historia. LINQ jest łatwy i przyjemny, a da Tobie podstawy do pracy z EF.