Visual Studio 2017

  • VB.NET

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von Stephan73.

    Visual Studio 2017

    Hallo zusammen!

    Bisher habe ich kleinere Datenbankanwendungen unter Microsoft Access erstellt. Nun jedoch kommen auch Rechner in Frage, wo kein Access installiert ist, eine Runtime möchte ich jedoch ausschliessen. Die neuen Programme sollen Windows Anwendungen (*.exe) sein.

    Somit stehe ich vor der Entscheidung auf andere Programme umzusteigen. Wie ich gesehen habe, ist das Visual Studio Community 2017 kostenlos und Windows Anwendungen können darunter erstellt werden. Als Programmiersprache würde VB zum Einsatz kommen. Da dies für mich "Neuland" ist, anbei einige Fragen:

    1.) Ist die kostenlose Visual Studio Community 2017 Version geeignet, um kleinere Windows Anwendungen zu erstellen und diese auch zu verteilen?
    2.) Welches Datenbankmodell käme in Frage bei VS? Microsoft Access möchte ich hier ausschliessen. Access müsste ja somit wiederum auf den Rechnern installiert sein?!

    Für einige Tips und Anregungen, welche Programme am Besten geeignet wären, wäre ich sehr dankbar.
    1.)
    Ja, mit der kostenlosen Version darf man auch Programme entwickeln, diese man auch z.b Verkaufen darf!

    2.)
    Ich empfehle dir MS SQL-Compact, diese kann man dann auch ohne MS-Access verwenden.

    Link:
    https://de.wikipedia.org/wiki/Microsoft_SQL_Server_Compact
    :thumbsup:
    Visual Basic.NET 8o
    MS-SQL
    8o
    Hallo und erst einmal Danke für die ersten Antworten.

    1.) Wenn ich das richtig interpretiere, wäre das DataSet ein Auslagern der Daten in eine XML Datei, die wiederum temporär eingelesen werden in die Anwendung, während mit dem SQL-Compact eine "echte" Datenbank vorhanden wäre, die auch mit der Anwendung verteilt würde? Ist das korrekt?

    2.) Ist mit SQL-Compact die Datenbank in der Anwendung enthalten oder aber als eigenständige Datei vorhanden? Dies mit dem Hintergrund, ob die Anwendung dann von mehreren Arbeitsplätzen gleichzeitig gestartet und auf die Daten zugegriffen werden kann?
    Ein DataSet ist eine datenbankähnliche, projektinterne Verwaltung von Daten. Man kann die Daten irgendwann in ne XML-Datei schreiben und die später wieder da raus holen. Muss es aber nicht. Und ne "echte" Datenbank? Verwaltet Daten, die sie spätestens beim PC-Herunterfahren in ne Datei schreibt. Also zumindest in dem Punkt kein relevanter Unterschied zu nem DataSet.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Nicht ganz.
    Ein Dataset legt alle Daten im RAM ab und das kann bei großer Datenmengen zu Problemen führen.
    Bei einem SQL Server landen die Daten ziemlich direkt auf der Platte. Zudem kann man mit Hilfe des Transaktion Logs Änderungen genau nachvollziehen.
    Man kann Indizes setzen um schneller zu suchen und zu sortieren.
    Und man lädt nur die Benötigten Daten in die Anwendung. Und und und
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    Ist mit SQL-Compact die Datenbank in der Anwendung enthalten oder aber als eigenständige Datei vorhanden? Dies mit dem Hintergrund, ob die Anwendung dann von mehreren Arbeitsplätzen gleichzeitig gestartet und auf die Daten zugegriffen werden kann?

    MS SQL-Compact de.wikipedia.org/wiki/Microsoft_SQL_Server_Compact
    ist nicht als Windows-Serverprozess ausführbar und läuft ausschließlich im Kontext der Anwendung.
    Die Datenbankdatei (*.sdf) kann man jedoch kopieren und somit einer anderen Anwendung zur Verfügung stellen.
    Bei Access verhält es sich ähnlich.

    Wenn Anwendungen gleichzeitig auf eine gemeinsame Datenbank zugreifen müssen, dann benötigt man immer
    noch einen separaten Server mit einem "richtigen" Datenbanksystem (MS-SQL Server, Oracle DB Server, usw).
    An manchen Tagen gibt es zu allem Überfluss auch noch Ärger!
    Nicht ohne Weiteres, selbes gilt für Access und SQL Compact.

    Wenn mehrere Rechner auf die Selbe DB zugreifen sollen, brauchst du einen zentralen Dienst/zentrale Anwendung, der/die sich darum kümmert, die Anfragen geordnet in die DB zu bekommen.

    Mit SQLite ist es schon möglich, aber die verschiedenen Rechner blockieren sich gegenseitig enorm. Selbst wenn jede Tabelle ihre eigene Datei bekommt. Sobald einer schriebt, können die anderen nichts mehr mit der Tabelle machen, bis diese wieder freigegeben ist.

    Aus diesem Grund gibt es ja gerade DBMS Systeme wie MySQL, Microsoft SQL Server, Oracle usw. Diese kümmern sich schon darum, sodass deine Anwendungen sich lediglich verbinden müssen, und du den Großteil der Probleme bereits hinter dir hast.

    Darüber hinaus werden die Daten auch optimiert abgelegt, und dank Puffer kann ein solches DBMS System innerhalb von Millisekunden antworten, anstatt erst alles von der Platte lesen zu müssen.
    SQLite ist ebenfalls eine lokale Datenbank.
    Wenn du einen zentralen Speicher benötigst, dann kommst du nicht um einen SQL Server drum herum
    MS SQL Express kann eine DB bis 10GB Größe kostenfrei betreiben
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    Ja der MS SQL Express ist kostenfrei.
    Einen SQL Server, egal von welchem Hersteller, installiert man einmal und alle Clients können darauf zugreifen.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.

    Stephan73 schrieb:

    Würde aber bedeuten, bei der Installationsroutine beim Anwender müsste der MS SQL Express Server mit installiert werden?!
    Besser wäre es, dass du dies in die Systemvoraussetzungen deiner Anwendung integrierst. So kannst du einfach davon ausgehen, dass dieser dort ist, und musst dich nicht um dessen Installation kümmern. (leider in der Regel schon)

    Gäbe es da nicht ein kleines Detail. Meiner Erfahrung nach, sind SQL Server Express (2016/17) so wie sie normal installiert werden, nicht für die Benutzung durch mehrere Rechner ausgelegt. Man muss zunächst über das Management Tool das TCP Protokoll für den Server aktivieren, und dann sicherstellen, dass der SQLBowser aktiv ist. Sonst bekommt man keine Verbindung von einem anderen Rechner aus. Das wissen Teilweise nicht mal IT-Häuser die SQL Server Instanzen für andere Firmen Bereitstellen und warten. Vermutlich weil sie keine Express Varianten Installieren.
    Warum nicht einfach mysql.com/de/why-mysql/windows/

    Mit dem Installer kann man den MySql Dienst als Entwicklungs -oder Produktionsserver einrichten.
    Du kannst einstellen ob ein permanenter Dienst erstellt werden soll, oder du manuell den Server starten willst. Du hast im Allgemeinen eine gute Kontrolle darüber, was laufen soll und was nicht.
    Wenn die bei Oracle es nicht schaffen würden jedes mal etwas zu verkacken, was in vorigen Versionen bereits gefixt war...

    Dazu ist die Konfiguration mit den 3 Einstellungsmöglichkeiten(Entwicklungsmaschine, Server, dedizierter Server) ein Witz.
    Seit 5.5 bis jetzt 8.0.11 hab ich es noch nie erlebt, weder auf meinen Rechnern/Servern, noch auf denen von Kunden, dass die Einstellung irgendetwas verändert. Man muss immer nachträglich in der my.ini dem Server die Puffer und Logs vergrößern.

    Aber mal abgesehen von den teils vebuggten Tools (also die Workbench), kann ich auch MySQL empfehlen.
    Es ist m.E. die bisher einfachste Installation von Server + Management Tool, und ist schnell eingearbeitet.

    Achja ein Hinweis noch.
    Sollte jemals in der näheren Zukunft die Möglichkeit bestehen, das Programm auch mal auf Oracle und/oder MSSQL zu übertragen, dann plane sorgfältigst die SQL Befehle die du an den Server schickst.
    Oracle, Microsoft und Oracle ähh Sun ähh MySQL sind sich da nämlich nicht sonderlich einig.
    Hallo!

    Danke für die Antworten.

    Zu dem MS SQL Compact hätte ich noch Fragen:

    1.) Wird der MS SQL Compact noch in Windows 10 unterstützt? In Foren habe ich gelesen, dieser wird nicht mehr weiterentwickelt und es wird empfohlen, den SQL Server LocalDB zu verwenden?!

    2.) Angenommen das Programm soll optional als Einzelplatz und Netzwerkversion erstellt werden. Kann die mit SQL Server LocalDB erstellte Datenbakn auch für einen SQL Server verwendet werden? Oder gibt es hier in den Datenbanken grundlegende Unterschiede?