BV.NET und Datenbankprogrammierung

[Siegfried Hubert]

Hallo Leute,
wie geeignet ist VB.NET zu Datenbankprogrammierung?

Wie sieht es mit den Steuerelementen und anderen Neuerungen aus?
Gibt es hier wesentliche Verbesserungen für die Datenbankprogrammierung?

Bisher habe ich viel in Access gemacht.
Jetzt überlege ich Datenbankanwendungen mit VB.NET zu programmieren.
Macht das Sinn?

Gruß Siegfried

[Andreas Kosch]

Hallo,

das kommt darauf an, welche Entwicklungsumgebung genutzt wird. Mit den kostenlosen Tools aus dem .NET Framework (Notepad als Editor + Kommandozeilen-Compiler vbc.exe) ist es etwas unbequem. Aber mit Visual Studio .NET ist ein sehr effektives (visuelles) Arbeiten möglich.

>Macht das Sinn?

Irgendwann muss jeder wechseln, die Frage ist nur, ob man sofort ein echtes Projekt beginnt oder nicht. In jedem Fall macht das Einarbeiten in die massiven Neuerungen von .NET bereits jetzt Sinn.

[Siegfried Hubert]

Hallo Andreas,
danke für Deine Antwort. :-)

Ich meinte mit "Sinn" den Wechsel der Frondend von Access zu VS.NET.
Also macht es Sinn, DAtenbankanwendungen zukünftig z.B. mit Visual Basic.NET bzw. ADO.NET zu erstellen, oder sollte man bei Access bleiben?

Gruß Siegfrie

[Andreas Kosch]

Hallo,

wenn als Datenbank eine SQL-Datenbank genutzt wird, macht der Wechsel in jedem Fall Sinn. Falls "nur" eine MDB verwendet wird, ist die Anbindung innerhalb von ACCESS natürlich vom Funktionsumfang her ausgeprägter als bei .NET. Aber dieser Schwund machte sich ja auch zwischen DAO und ADO bemerkbar, ADO.NET geht einen weiteren Schritt in die Richtung weg von MDB und hin zu SQL-Datenbanken

[Siegfried Hubert]

Access z.B. ist eine SQL - Datenbank. :-)
Was bedeutet "nur eine MDB"?

Was bedeutet die folgende Aussage?
"Aber dieser Schwund machte sich ja auch zwischen DAO und ADO bemerkbar, ADO.NET geht einen weiteren Schritt in die Richtung weg von MDB und hin zu SQL-Datenbanken."

Wie lautet denn nun die Empfehlung?
Sollte man eher weiterhin mit Access entwickeln, oder zukünftig mit NET?

Gruß Siegfrie

[Andreas Kosch]

Hallo,

>Aber dieser Schwund machte sich ja auch zwischen DAO und ADO bemerkbar, .....

das DAO-Objektmodell stand nur für die Microsoft Jet Engine zur Verfügung und war somit den MDB-Datenbanken "auf den Leib" geschrieben.

ADO als eierlegende Wollmilchsau deckt sowohl ACCESS als auch SQL-Datenbanken ab, wobei das ADO-Objektmodell deutlich flexibler als DAO ist. Unter ADO kann man zwischen den serverseitigen und clientseitigen Cursors wählen, so dass über die Kombination von clUseServer und cmdTableDirect auch MDB-Datenbanken gut unterstützt werden.

Mit ADO.NET entfallen die serverseitigen Cursor, da Datenmengen nur noch in einem Modus betrieben werden, der unter ADO dem Modus clUseClient + ltBatchOptimistic entspricht

[Siegfried Hubert]

Und wie lautet nun die Empfehlung: Weiterhin Access oder VB.NET zu Datenbankprogrammierung? :-)

Gruß Siegfrie

[Andreas Kosch]

Hallo,

wenn man mit den sich zwangsläufig ergebenden Einschränkungen leben kann, wird VB.NET die "bessere" Option sein

[Siegfried Hubert]

Welche Einschränkungen wären das?
Warum wäre VB.NET die bessere Alternative?

Könntest Du Deine Meinung bitte noch etwas näher ... :-)

Gruß Siegfrie

[Christian Wald]

Hallo miteinander!

Wer hat eine Lösung für folgendes Problem?

Anbinden eines SQl-Servers mit zwei Tabellen und deren Beziehungen wo eine Tabelle Null-Werte aufweist.

Entweder bindet VB nichts oder alles Daten wo kein NULL-Werte enthalten ist

[Andreas Kosch]

Hallo,

das hat nichts mit VB zu tun, sondern betrifft bereits die SELECT-Abfrage. Der Zustand NULL ist in der SQL-Welt ein Sonderfall, so dass der SQL-Standard explizit die Abfragen <b>IS NULL</b> bzw. <b>IS NOT NULL</b> vorsieht. Wenn man in einem JOIN bei der SELECT-Abfrage 2 Tabellen miteinander verbindet, so findet der Vergleich über <b>=</b> nur die Datensätze, in denen in der Spalte der Zustand NULL nicht vorkommt

[Christian Wald]

Dank