SELECT zwracający ilość pozycji w tabeli i wpisanie wyniku do zmiennej

0

Mam takie pytanie, podłączam się do bazy danych i chce zrobić select'a który zwróci mi ilość pozycji w danej tabelce i tą zwróconą wartość chce przypisać do jakiejś zmiennej żeby potem wykorzystać w pętli. Jak to można zrobić?

0
select count(*) from <nazwa_tabeli>
0

najłatwiejsza metoda to użyć Linq. Ogólnie mówiąc powala on przy użyciu języka c# wykonywać zapytania z TSQL np.wynik select wstawić do zmiennej i później przejrzeć za pomocą polecenia foreach

0

No tak może nie do końca dobrze opisałem mój problem. Wiem jak zapytanie ma wyglądać. Nie wiem jak jego wynik przypisać sobie np to int ilosc_wierszy.

0

Autorowi chyba nie chodziło o SELECT COUNT(*) FROM <nazwa_tabeli> gdyż chce on też przejrzeć wyniki. W TSQL można wykorzystać w procedurze przechowywanej KURSOR i polecenie Fetch, ale jak już wyżej pisałem warto zainwestować w naukę Linq bo mi on osobiście zrewolucjonizował pisanie aplikacji w asp.net

0
polaczenie = new SqlConnection();
            polaczenie.ConnectionString = "Data Source=" + serwer + ";" + "Trusted_Connection=yes;" + "database=" + bazaDanych;
            try
            {
                polaczenie.Open();
                lbInfo.Text = "Połączono z bazą danych...";
                lbInfo.Refresh();
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.ToString(),"Błąd połączenia z bazą danych");
            }
int czy_istnieje=0;
            string ile_produktow_w_bazie = "select count(*) from tw__Towar where tw_kod ="+kod+";";
            sqlc = new SqlCommand(ile_produktow_w_bazie);
            sqlc.Connection = this.polaczenie;
            sqlc.ExecuteNonQuery();

i teraz chcę wiedzieć czy select zwraca 0 czy więcej i użyć tego w if'e.

1
conn = new SqlConnection(ss);
        comm = new SqlCommand("spOdNr", conn);
        comm.CommandType = CommandType.StoredProcedure;
        comm.Parameters.AddWithValue("@id", idr);
        comm.Connection.Open();
        Object obj2 = comm.ExecuteScalar();
        if ((obj2 != null) && (obj2 !=System.DBNull.Value))
        {
            RR2 = Convert.ToInt32(obj2);
        }
        comm.Connection.Close();
0

To samo w LINQ

 DataClassesRejestryLinqDataContext dbr = new DataClassesRejestryLinqDataContext();
 var startnr = dbr.RejestryLinqs.Single(p => p.ID == Convert.ToInt32(Session["idr"].ToString()));
 RR2 = startnr.OdNr;
2
cw napisał(a):

jak już wyżej pisałem warto zainwestować w naukę Linq bo mi on osobiście zrewolucjonizował pisanie aplikacji w asp.net

Czy na pewno warto?
LINQ to SQL (bo to Ci chodzi, a nie o LINQ) niby jest wspierany, ale przez sam Microsoft określany jako "legacy". EF jest ich głównym ORMem, i to należy brać pod uwagę, przy nauce czegokolwiek.

cw napisał(a):
 var startnr = dbr.RejestryLinqs.Single(p => p.ID == Convert.ToInt32(Session["idr"].ToString()));

W tej lambdzie może zostać rzucony NullReferenceException albo FormatException, nie wspominając już o tym, że lepiej byłoby użyć SingleOrDefault.

0

nie wchodząc w szczegóły nullreferenceexception nie wystąpi gdyż pewne ograniczenia zostały nałożone bezpośrednio w MSSQL i na 100% rekord w bazie istnieje i ma ustawiony numer początkowy dlatego też nie ma potrzeby stosować SingleofDefault czy FirstofDefault . Mówiąc linq oczywiście miałem na myśli Linq to SQL choć mi osobiści przydaje się też Linq to XML np. do wczytywania plików konfiguracyjnych czy też eksportu i importu rekordów z/do bazy. Co do EF równie dobrze można powiedzieć, że ASP.NET to też technika baz przyszłości bo jest MVC, ale idąc tym tokiem myślenia to VisaulBasic też można byłoby uznać za pomyłkę MS, a powstało w nim wiele dobrych programów. Pewne języki programowania czy technologię mają swoją niszę i świetnie nadają się do pewnych konkretnych celów więc moim zdaniem dyskusja o wyższości jednego języka na innym przypomina trochę dyskusję o wyższości świąt Bożego Narodzenia nad Wielkanocą i odwrotnie.

2
cw napisał(a):

nie wchodząc w szczegóły nullreferenceexception nie wystąpi gdyż pewne ograniczenia zostały nałożone bezpośrednio w MSSQL i na 100% rekord w bazie istnieje i ma ustawiony numer początkowy dlatego też nie ma potrzeby stosować SingleofDefault czy FirstofDefault .

To po kolei, bo nic nie zrozumiałeś:

  1. Gdy Session["idr"] nie będzie istniało, czyli będzie null, a Ty wywołasz na nim ToString() to poleci NullReferenceException. Jak za każdym razem, gdy próbujesz wywoływać metodę instancyjną na null.
  2. Jeżeli żaden rekord nie spełni warunku z lambdy w metodzie Single, to zostanie rzucony wyjątek InvalidOperationException z komunikatem Seqence contains no matching element. Dlatego właśnie lepiej użyć SingleOrDefault.

Co do EF równie dobrze można powiedzieć, że ASP.NET to też technika baz przyszłości bo jest MVC, ale idąc tym tokiem myślenia to VisaulBasic też można byłoby uznać za pomyłkę MS, a powstało w nim wiele dobrych programów.

MVC to część ASP.NET, zgaduję, że chodzi Ci o WebFormsy.

Jakim tokiem myślenia?
Microsoft nie nazywa WebFormsów jako "legacy", ani nie zamierza się z nich wycofywać. Wręcz przeciwnie - ciągle podkreśla, że będzie wspierał oba frameworki webowe.
Entity Framework jest ciągle rozwijany i jest głównym ORMem Microsoftu, natomiast ostatnie zmiany w LINQ to SQL miały miejsce chyba w .NET 4.0. LINQ to SQL nie wspiera nawet relacji wiele do wielu!

Zobacz, co sam Microsoft twierdzi choćby tutaj: http://msdn.microsoft.com/en-us/library/ms178359.aspx#orm

The most commonly used ORMs that work with ASP.NET are the following:

The ADO.NET Entity Framework is the main ORM that Microsoft provides for the .NET Framework.

LINQ to SQL is a legacy ORM that Microsoft provides. (Don't confuse LINQ to SQL with LINQ. For information about LINQ, see LINQ versus SQL later in this topic.)

NHibernate is an open source ORM for the .NET Framework.

I co, Twoim zdaniem, takiego złego jest w EF, żeby się go nie uczyć?

Pewne języki programowania czy technologię mają swoją niszę i świetnie nadają się do pewnych konkretnych celów więc moim zdaniem dyskusja o wyższości jednego języka na innym przypomina trochę dyskusję o wyższości świąt Bożego Narodzenia nad Wielkanocą i odwrotnie.

Świetnie, ale nikt tu nie dyskutuje o językach. Z Visual Basic Ty wyskoczyłeś jak filip z konopi.

0

session "idr" zawsze istnieje, a jeżeli dojdzie do sytuacji, że jednak będzie miała wartość null to błąd zostanie obsłużony wcześniej i zapytanie nie zostanie wywołane

Faktycznie zrobiłem skrót myślowy i zamiast WebForms błędnie użyłem Asp.Net

Przytoczyłem przykład Visual Basic ponieważ często w literaturze WebForms są określane jako "Visual Basic dla aplikacji webowych" ze względu na filozofię tworzenia oprogramowania: szybkie tworzenie aplikacji za pomocą myszki, dużo automatycznie generowanego kodu, ale kosztem wydajności i przejrzystości aplikacji

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

0
cw napisał(a):

session "idr" zawsze istnieje

Zawsze? Uruchomię nową, czystą aplikację ASP.NET i już tam w Session będę miał coś pod kluczem "idr"?

Przytoczyłem przykład Visual Basic ponieważ często w literaturze WebForms są określane jako "Visual Basic dla aplikacji webowych" ze względu na filozofię tworzenia oprogramowania: szybkie tworzenie aplikacji za pomocą myszki, dużo automatycznie generowanego kodu, ale kosztem wydajności i przejrzystości aplikacji

No cóż, nie sposób się z tym nie zgodzić. :) Ale nikt WebFormsów nie chce przecież ubijać. VB chyba też nie. (Nie wiem, nie piszę w nim.)

0

batonik, spróbuj tego

SqlDataAdapter da = new SqlDataAdapter();
DataSet ds = new DataSet();
SqlConnection con = new SqlConnection(połączenie);
 
da.SelectCommand = new SqlCommand(kwerenda,polaczenie);
con.Open();
da.Fill(ds);
con.Close();
int zmienna =ds.Tables[0];


0

wykorzystałem takie coś:

string zapytanie = "select count(*) from Tabelka where kod=@KOD;";
            sqlc = new SqlCommand(zapytanie);
            sqlc.Connection = this.polaczenie;
            sqlc.Parameters.Add("@KOD",SqlDbType.VarChar);
            sqlc.Parameters["@KOD"].Value = kod;
            int wynik = (Int32)sqlc.ExecuteScalar(); 

i działa;)
Dzięki za podpowiedzi;)

0

Widać że Microsoft idzie śladem Borlanda/Embarcadero, zmieniając ORM-y z wersji na wersję jak rękawiczki.
Jutro się okaże, że EF jest legacy bo powstanie nowy, lepszy (i nikomu niepotrzebny).

0
Azarien napisał(a):

Widać że Microsoft idzie śladem Borlanda/Embarcadero, zmieniając ORM-y z wersji na wersję jak rękawiczki.
Jutro się okaże, że EF jest legacy bo powstanie nowy, lepszy (i nikomu niepotrzebny).

Bez przesady, przez 12 lat dorobili się istnienia raptem dwóch ORMów, i kładą większy nacisk na rozwój jednego z nich.

1 użytkowników online, w tym zalogowanych: 0, gości: 1