PureBoard

@xaby ja das ist gut, nur mein erster Gedanke war nun mal eigentlich eine Datenbank. Weis auch nicht warum, wohl besser. Aber die Idee mit einzelnen Dateien ist spitze. Genau die werd ich verfolgen. Ist im Prinzip genau das was ch such, das ist so einfach.
und ich such doch eigentlich kein Telefonbuch, ne war einfach der Baum mit dem vielen Wald den man nicht sieht. oder waren das Blätter am Ast am Baum das man nicht sieht?

Jetzt kann ich beruhigt schlafen und morgen voller Tatendrang anfangen.

Ein großes Danke an alle

Allerdings is die Sache mit den einzelnen Dateien mit Vorsicht zu geniessen wenn man viele Datensätze hat kann das schnell mal richtig viel Speicher fressen als kleiner Vergleich:

Datei mit 202258 Einträgen -> 3.907.584 Bytes*
Datei mit 7 Einträgen -> 4.096 Bytes*

Ergo

28894 Dateien mit je 7 Einträgen -> 118.349.824 Bytes*

* Größe auf Datenträger

Das stimmt.

Jede Datei wird soviel verbrauchen wie das Cluster groß ist.
Bei Windows wohl als Standardgröße 4KByte.

Pro Kind also 4KByte. (auf Festplatte)

Auf Wechseldatenträgern 512 Byte ... (wenn FAT)
Oder je nach dem wie groß es sie sind. (mehr Zeichen, etc.)


Aber selbst beim gesamten Kindergarten: ~ 150 Einträge (Kinder)

bei 4KByte ~ 600KByte
bei FAT ~ 80KByte

Und mit ZIP/RAR zum Transportieren ...

Aber da kannste auch dann wieder eine Excel-Tabelle draus machen.

Würd mich freuen, wenn du uns deine Ergebnis auch mitteilst.

Viel Erfolg.

dietmar hat geschrieben:mein erster Gedanke war nun mal eigentlich eine Datenbank. Weis auch nicht warum, wohl besser.

kommt ganz darauf an, was Du genau mit Deinem Programm machen willst
und wie viele Leute gleichzeitig mit dem Programm arbeiten werden.

Hast Du schon DB-Erfahrungen gemacht? Wenn nicht, dann musst Du
bedenken, dass die Einarbeitungszeit nicht zu unterschätzen ist.

Grüße ... Kiffi

@Kiffi
Kannst du vielleicht mal den Code eines Grundgerüstes ausstellen?

Wenn man es nicht mit mehreren Dateien machen möchte und nicht über die Dateifreigabe ...

Dann funktioniert es doch so:

- Ein Server hat die Datenbank in irgendeiner Form und Struktur vorliegen
- die Clients stellen Anfragen an den Server und dieser sendet dann die Antworten, wenn der Client die Berechtigung für die jeweilige Anfrage aufweist.

So die Theorie

Der Vorteil ist, dass die Rechtevergabe unabhängig vom verwendeten Betriebssystem läuft. Es ist ebenso möglich Anfragen nicht nur im LAN, sondern auch im WAN (WideAreaNetwork / Internet) zu haben.
Die Dateistruktur nimmt weniger Platz weg als einzelne Dateien.

Darüber hinaus muss sich der Client nicht um die Struktur der Daten kümmern. Für ihn sind es immer wieder die selben Anfragen.
Selbst wenn die Struktur komplett umgeändert wird oder die Datenbank umzieht.

>> Nachteil

Durch die Server-Client-Architektur ist es ein erheblicher Mehraufwand, der sich nicht unbedingt bei Einzelplatzanwendungen lohnt.


Wie realisiert man zum Beispiel den Zugriff auf eine Excel-Tabelle, auf die mehrere User zugreifen können.
Die ganze Sache sollte aber auch auf einem Rechner laufen.

Achja, und wenn möglich, sollte es keine Server-Software-Voraussetzungen geben.

Ich glaube, dass das ODBC-System selbst auf einem einzelnen Rechner so läuft.
Allerdings wohl nur ein bisschen davon.
Ich glaube, dass nur am Anfang beim Öffnen eine Verbindung zum "Server" aufgebaut wird. Alle Spalten und Zeilen geladen werden.
Und dann die Verbindung zum "Server" beendet wird.
Beim Speichern wieder hergestellt und alle Änderungen gesichert werden.

Vorteil hier bei, die Anwendungssoftware benötigt nicht laufend eine Verbindung zu einem virtuellen Server und kann mit eigenen Routinen auf die Datenfelder zugreifen.
Nachteil: Wenn die Excel-Tabelle offen ist, können andere sie nur noch schreibgeschützt öffnen.

Vielleicht entwickeln wir alle zusammen mal 4 Tutorials.
- eins haben wir ja schon (eine *.csv Datei)
- eine andere gibt es auch schon (wie öffne ich eine Excel-Tabelle)
- die Sache mit den einzelnen Dateien ist auch noch einfach
- und wie man Datenpakete zwischen Rechnern austauscht ...
(Okay, das weiß ich nicht, steht hier sicherlich irgendwo)

Aber was wäre, wenn wir die "vorhandene" Telefonbuch-Software nehmen und die Sache demonstrieren. Als DatenBank-Tutorial.

Wenn man zum Beispiel 100 Datensätze in einer Excel-Tabelle hat und von einem oder dem eigenen Rechner erfahren möchte,
was in der Tabelle steht.
Und sagen wir man sucht etwas. Einen bestimmten Begriff.

Da gibt es ja nun auch wieder viele Möglichkeiten.

Entweder man schickt die ganze Excel-Datei und der Client sucht.
Oder der Server muss suchen und schickt das Ergebnis zurück.

Würde mich freuen, wenn da jemand ein leicht verständliches Beispiel hat.

Dank euch.

Ne das mit Datenbank ist gestorben. Bin gerade dabei mit vielen einzelnen Dateien zu arbeiten. Da die Dateien nur kurz geöffnet werden beim einlesen und dann im Arbeitsspeicher stehhen sollte der Zugriff auch mit mehren Personen gehen. Selbes bei Änderungen. So ist eine Datenbank tatsächlich unnötig.

Außerdem existiert in diesem KiGa nur ein PC so das sowieso immer nur eine Person Zugriff hat (ist ein öffentlicher die sind immer arm).

Sicher würd ich mein Source veröffntlichen, aber da würden sich euch die Haare stellen. Für mich funktionierts, aber für andere siehts gruenhaft aus.

Hallo Dietmar,
hier habe ich ein Beispiel wie ich es damals gelöst habe ( mit einer Textdatei ). Daten anlegen, anzeigen, löschen, nach bestimmten Kriterien ( Datum ) Daten ausgeben ( Anzeige in einem ListIconGadget ). Wenn du noch Interesse hast, kannst du es ja nach deinen Bedüfnissen was die Felder und Feldlänge angeht anpassen. Später habe ich dann noch eine allgemeine Suchfunktion ( nicht nur nach Datum, sondern nach allem was man in die Suchmaske eingegeben hat ) eingefügt, allerdings nur in der Türkischen Version.

Hier der Link http://www.purebasic.fr/german/viewtopi ... ht=#115134

Wenn nicht - dann eben nur als Beispiel.

Das hilft mir auf jeden Fall weiter, das eine oder andere werd ich direkt übernehmen. Allerdings entspricht nicht alles meinen Vorstellungen. Ich freu mich aber wirklich über den Source. Vielen Dank auch.