---

Servus

Für eine Anwendung benötige ich die Möglichkeit verschiedene Werte in Tabellen abzulegen (max ca. 40 x 8 Tabelle).
Diese Tabellen dienen als Input für eine Benutzeroberfläche. Die Tabellen möchte ich nicht etwa in Excel ablegen (Excel nicht immer vorhanden).
Dabei benötige ich Möglichkeiten aus den Tabellen schnell Werte(Paare) herauszufiltern.
Folgende Ideen habe ich bis jetzt:
- ini-Files (ggf etwas umständlich zum Filtern)
- txt-Files (jedemal die Datei neu einladen und verarbeiten?)
- SQLite-Datenbank
- DataSet bzw RecordSet (als XML gespeichert)
Was ist einfach zu implementieren und bietet trotzdem die Möglichkeit die Daten zu durchsuchen/filtern?
Gibt es noch einfache andere Datenbanken/Tabelle/Möglichkeiten Daten abzulegen?

Gruß
Bernd

------------------
Warum einfach, wenn es auch kompliziert geht.

------------------
Warum einfach, wenn es auch kompliziert geht.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Bernd,
wenn du doch nicht mal Excel überall zur Verfügung hast, dann wird wohl SQLLite keine Alternative sein oder doch?  Aber mal davon ab, würde ich weder mit Ini noch mit xml-Dateien arbeiten, wenn du doch eine "so kleine" Tabelle benötigst.
Ich pers. würde wahrscheinlich eine Trennzeichen definierte Textdatei erstellen und diese Daten auslesen und verwenden. Das auslesen verbraucht kaum Leistung und solange die Daten immer gleich bleiben, kann man diese Datei auch auf den lokalen Rechner in ein definiertes Verzeichnis kopieren. Dabei würden dann die Trennzeichen die Spalte und der Zeilenwechsel die Zeile definieren. Sehr simpel und einfach gestrickt. Die Frage ist halt, was es wirklich sein soll. Wenn es z.B. über einen Server laufen soll, mit dynamischen Zugriffen und ständig geänderten Daten, dann würdest du z.B. um eine tatsächliche Datenbank ala SQL nicht herum kommen. Hier kann man dann ODBC-Treiber verwenden...

------------------
MFG
Rick Schulz

Nettiquette (CAD.de)  -  Was ist die Systeminfo?  -  Wie man Fragen richtig stellt.  -  Unities

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus Rick

Ich dachte bei einer SQLite-Datenbank reicht es auf die sqlite-Datei zuzugreifen (im Programmverzechnis meiner Anwendung) (siehe auch Wikipedia).

Gruß
Bernd

------------------
Warum einfach, wenn es auch kompliziert geht.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Bernd,

ich würde an dieser Stelle XML favorisieren.

- ist leicht portierbar da nur ASCII
- ist struckturiert und in gewissem Maße selbstbeschreibend
- ist leicht duchsuchbar und filterbar (XPATH)
- es gibt eine Menge Werzeuge zur Bearbeitung von XML (DOM als COM, .NET bitete einen ganzen Namensraum usw.)

Datenbankfunktionen wie schared Zugriff, nutzerabhängige Zugriffsrechte usw. kann man allerdings nicht erwarten.

Gruß
Peter

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Bernd,

anstelle von SQLite könnte man auch Access verwenden. Schon mal darüber nachgedacht? Dazu die Datenbank - Datei entweder lokal jeder Anwendung mitgeben, oder auf einer Freigabe auf dem Server ablegen, wo jeder drauf zugreifen darf.
Lässt sich noch dazu mit einem vb.net Express recht gut ansprechen, bzw. macht der Designer für dich die ganze Arbeit. 
Grüße und HTH

Tobias

------------------
Besucht mich doch mal in meiner Tischlerei

"...Kommunikation ist nur so gut wie ihr Ergebnis..." - frei nach Richard Bandler / John Grinder

"...Wenn du das tust, was du schon immer tust, wirst du auch nur das erhalten, was du schon immer erhalten hast..."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus
Danke für die Antworten.

@Tobias:
Dann muss doch immer Access auf dem entsprechenden Rechner installiert sein, oder?
Dies ist leider nicht der Fall.

Gruß
Bernd

------------------
Warum einfach, wenn es auch kompliziert geht.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nein, muss nicht. Nur zum entwickeln der Datenbank.
Der Treiber zum Zugriff sollte standardmäßig bei Windows dabei sein (ODBC, wenn ich mich recht entsinne).
Das Lesen/Schreiben auf die Datenbank übernimmt dein vb.net Code, der dann entweder die Daten aus der DB ausliest, um deine Benutzeroberfläche zu füllen, oder Daten in die DB schreibt, um geänderte Werte zu speichern.
Es ist, allerdings weiß ich das nicht so genau, wohl auch mit einem Visual Studio (nicht der Express Variante) möglich, die DB zu erstellen und damit die Tabellen anzulegen.
[Edit]Es gibt zum vb.net Express auch einen SQL - Server in der Express Edition, der es dir zumindest erlaubt, eine Datenbank (oder mehrere) einzuhängen und mit Tabellen zu versehen. Vielleicht bringt dich das weiter, dass du dir den SQL - Server installierst und deine DB darauf laufen lässt.[/Edit]
Grüße und HTH

Tobias

------------------
Besucht mich doch mal in meiner Tischlerei

"...Kommunikation ist nur so gut wie ihr Ergebnis..." - frei nach Richard Bandler / John Grinder

"...Wenn du das tust, was du schon immer tust, wirst du auch nur das erhalten, was du schon immer erhalten hast..."

[Diese Nachricht wurde von MWN am 14. Nov. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

Zitat:

---

Dann muss doch immer Access auf dem entsprechenden Rechner installiert sein, oder?

---

mitnichten!

Windowsbordmittel sind ausreichend, der WSH versteht z.B. folgendes

Code:

---

set oOLEDb = createobject("ADODB.Connection")
oOLEDb.open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source='d:\probe\meine kleine datenbank.mdb'"

---

Damit ist eine Datenbank geöffnet, und man kann alles damit tun was auch Access tuen könnte.
Daten lesen, Datensätze oder ganze Tabellen anlegen und löschen, Relationen beschreiben, wer will kann auch interne Macros ausführen und sogar anlegen (aber wozu?)

Ein Beispiel: in der oben geöffneten Datenbank kann mann so eine Abfrage ausführen (SQL Syntax) und das Ergebniss in einem Recordset ablegen. Alles in VB Script unter WSH

Code:

---

set tbTAB1 = Createobject("ADODB.Recordset")
sqlQUER = "select *, Bauteile.Feld2 from `Messergebnisse DSW` P1, Bauteile where P1.Bauteil=Bauteile.Bauteil"
tbTAB1.open sqlQUER,oOLEDb,1,1

---

IDE's wie Visual Studio oder andere bieten mehr komfort bei der Entwicklung, die Funktionalität ist die gleiche.

Gruß
Peter

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

  

Zitat:

---

set oOLEDb = createobject("ADODB.Connection")
oOLEDb.open "Provider=Microsoft.Jet.OLEDB.4.0

---

Das ganze ist aber nur mit 32bit probiert .... oder mit 64bit auch den Officeteil installiert (Spezialausgabe Office2010-64bit Treiber), der sich aber nicht mit anderen Office-Installationsarten vertragt.
MDB-Datei und 64bit oder weitere Zukunft ist ein KO-Kriterium, man merkt an MS dass sie das einfach nicht wollen und alles auf SQL-Server ausrichten.
Siehe Würgaround MDB-Zugriff für 64bit hier: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13255 und gleich auch dazu, das funkt nicht mit/neben allen Office-Installationen, darum ist es für mich ein KO-Produkt.

Und SQL-Server zu installieren (auf jedem Client ein paar 100MB) nur um ein paar Zeilen einer Konfiguration zu speichen???

Ich würde in diesem Fall auch SQLite bevorzugen, da gibt's eine ManagedDLL für 32bit eine für 64bit, die legt man jeweils in sein BIN-Verzeichnis mit dazu und fertig. Oder eben XML, kann auch schon was und ist, so man mit eigenen Klassen arbeitet, auch schnell mit Serialisierung exportiert und importiert.

[Diese Nachricht wurde von ManfredPS am 15. Nov. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Bernd,

Du könntest ein Datagrid verwenden, welches am Start der Anwendung (und Ende) mit Daten aus einer .ini versorgt wird.

Gruß
Joachim

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Solange es in der Firma bleibt, würde ich auf nem Server den kostenlosen SQL - Server von MS installieren.
Der sollte eigentlich für das Vorhaben ausreichen und kann auch recht fix jeden Client mit Daten versorgen. Außerdem braucht man Änderungen nur an einer Stelle durchzuführen und nicht an 40.
Grüße und HTH

Tobias

------------------
Besucht mich doch mal in meiner Tischlerei

"...Kommunikation ist nur so gut wie ihr Ergebnis..." - frei nach Richard Bandler / John Grinder

"...Wenn du das tust, was du schon immer tust, wirst du auch nur das erhalten, was du schon immer erhalten hast..."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus
Danke euch allen.
Nachdem von Problemen mit 64bit und Access berichtet wurden, nehme ich von dieser Lösung eher wieder Abstand (obwohl diese mich schon überzeugt hatte)
Einen extra SQL-Server aufzusetzen, halte ich für übertrieben besonders wenn das Programm auch lokal auf einem Laptop) laufen soll.
Zur Verteilung einer zentralen XML/SQLite/ini-Datei kann ich schon auf eine bestehende Batch-Datei zugreifen/mitnutzen.
Nun liegt es wohl an mir, mich in eine Lösung einzuarbeiten.

Gruß
Bernd

------------------
Warum einfach, wenn es auch kompliziert geht.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP