Item-Manager für Access

[Imr3]

Public Function InventoryEquipmentInfo(InventoryID As Long, TextField As Object)
...

TextField.Text = ""
...

Genau so ist es

 

[Toast78]

Hm. Wenn du schon den Hinweis für Office 2003 in der Installationsanleitung befolgt hast (wovon ich stark ausgehe), dann weiß ich nicht mehr weiter.

 

[Imr3]

Ja hab mich nach der Installationsanweisung verhalten. Den Registrierungschlüssel hab ich kurzerhand gelöscht.

 

[Hunter[bo]]

irgendwie geht das bei mir nicht

immer wenn ich es öffnen will kommt eine fehler meldung das

"nicht erkenbares datenformat"

bitte helft mir

mfg hunter

p.s. ich benutzt office 97 ^^

 

[Toast78]

Das Datenbank-Format ist Access 2000. Das kannst du natürlich nicht öffnen.

Eine Umstellung auf Access 97 ist nicht vorgesehen.

 

[Hunter[bo]]

schade

 

[Toast78]

Habe heute nochmal ein weiteres kleines Update aufgespielt.
Ich schreibe Mitte März erstmal ein paar Klausuren. Direkt danach fängt das Semester auch wieder an. Insofern werde ich das Projekt D2-Item-Manager erstmal ruhen lassen.

 

[ThePale]

Ich werde es auch mal antesten.
Aber ob mich das von meiner guten alten Word-Liste wegbringt...

 

[alfons100]

Servus,

ich hätte da auch ein kleines Problem:
Immer beim Start des Programms erscheint die Meldung: "Tabellen wurden aktualisiert (...) Soll diese Option jetzt deaktiviert werden?" Wenn ich jetzt "Ja" anklicke geht gar nix mehr und die Tabelle verabschiedet sich.

Gibt es ne Möglichkeit, diese Abfrage zu verhindern?

Gruß
Alfons


P.S.:
Was ist eigentlich ein Boardcode???

 

[Acid800]

Auf sowas hab ich lange gewartet.

Hoffe der taugt was!


Thx

Mfg Acid

 

[tkdmatze]

hallo Toast

man muss dir schon ein kompliment machen,
steckt bestimmt ne menge arbeit drin

kleiner Bug am rande: wenn das windows verzeichnis nicht windows heisst
(heisst bei mir WINNT WIN 2000>all) muss man die datei selber kopieren
ist aber weit weniger tragisch

hats du die eigenschaften eigentlich als text oder werte gespeichert?
weil text hätte den nachteil, das man die itemsstats "nur" angezeigt bekommt
bei werten könnten man den char theoretisch auch "anziehen"

und nochmals Tolle Arbeit

 

[Toast78]

@Alfons100: Was heißt: Es geht gar nix mehr? Wenn du auf Ja klickst, werden beim nächsten Öffnen des Formulars "Ihr Inventar" die Datenquellen nicht mehr aktualisiert. Du müsstest dann eigentlich ein leeres "Ihr Inventar" vorfinden, wo auf der linken Seite nur ein Hauptknoten "Accounts" zu sehen ist.
Boardcode ist die Sprache, in der du deinen Text hier reinstellst. Hilfe zum Boardcode


@tkdMatze: Werte werden natürlich als Zahlen abgespeichert. Anders würde die Iteminfo im Hauptformular doch gar nicht funktionieren
Das mit dem Anziehen ist dann natürlich wieder so eine Sache: Soll das nur eine Simulation sein, oder ist das wirklich ein Charakter aus dem Inventar, welchen Wert hat welche Fertigkeit und zuletzt muss natürlich wieder eine Berechnung aus den Charaktereigenschften (Stärke, Geschicklichkeit), seinen Fertigkeiten und seiner Ausrüstung gemacht werden. Diese Idee reizt mich zwar, ist auch durchaus realisierbar, aber benötigt auch einiges an Zeit.
Und momentan habe ich davon viel zu wenig.

 

[Alloc]

Hi Toast,

wollte mir dein Prog auch gerade mal herunterladen ... Datei wurde von RapidShare wegen längerer inaktivität gelöscht (warum nutzen auch immer alle dieses RapidShare???).

Btw, warum muss das ganze auf M$ basieren, wo jeder erst noch extra Treiber etc brauch und nicht auf Freeware/OpenSource-Datenbanken/Sprachen? =)

mfG, Alloc

 

[Toast78]

Hi Toast,

wollte mir dein Prog auch gerade mal herunterladen ... Datei wurde von RapidShare wegen längerer inaktivität gelöscht (warum nutzen auch immer alle dieses RapidShare???).
Wenn du was genau so gutes (Dateigröße und Benutzerkomfort) kennst, lass mich hören. Natürlich sollte die Qulle auch immer verfügbar sein. Ist ja schließlich genau das, was dich nervt oder?
Btw, warum muss das ganze auf M$ basieren, wo jeder erst noch extra Treiber etc brauch und nicht auf Freeware/OpenSource-Datenbanken/Sprachen? =)

mfG, Alloc

Hm, was hast du denn da so vorzuschlagen? Von privater und beruflicher Seite kenne ich mich halt hervorragend mit Access aus. Ein wenig beschäftige ich mich auch privat mit Visual Basic. Das spiegelt sich in der splitter.ocx wieder. Also auch eine Komponente, die auf meinem Mist gewachsen ist.
Noch was zu Access: Access hat die Möglichkeit, alle Datensätze einer Tabelle (oder Abfrage) in einem Endlosformular darstellen zu lassen. Man hat also alle Datensätze auf einem Schlag in einer Übersicht. Um dies auf einer anderen Plattform manuell zu realisieren, wäre ein unvergleichbar großer Mehraufwand von Nöten. Wieder ein Pluspunkt für Access.

Aufgrund meines Studiums muss ich mich mit Java rumschlagen. Hätte ich mich für eine Realisierung in dieser Sprache entschieden, wäre ich vielleicht frühestens Ende des Jahres fertig. (Ich habe Mitte letzten Jahres mit der Programmierung angefangen). Hinzu kommt, dass für eine Java-Version ja immerhin keine Datenbank-Engine integriert wäre.

Kommen wir mal zur Datenverwaltung:
Access bringt hier schon seine eigene Datenbank mit. Würde man das unter VB programmieren, so wäre auch hier wieder der Verweis auf die Access-Engine nötig. Klar, man kann auch unter Access und Visual Basic mit ODBC-Verbindungen rumhampeln. Dementsprechend ließe sich auch schon die Freeware-Datenbank mySQL als Datenbank-Backend durchaus denkbar. Aber wie viele User wollen sich schon für so eine winzige Datenbank irgend einen SQL-Server installieren? Da könnte man ja gleich noch einen Webserver installieren, damit das ganze Programm dann in PHP entwickelt wird. Also ein bisschen viel des guten.
Bliebe noch die Möglichkeit, alles über Textdateien oder eigene Dateitypen zu machen. Aber hier stellt sich die Frage, wie optimal der Speicher verwaltet werden kann. Man könnte jetzt entgegnen, dass man doch schon mindestens 1 GB RAM zur Verfügung hätte. Aber wie viel RAM man hat sagt speziell hier nichts über die Geschwindigkeit des Programms aus. Gerade bei Java ist der tatsächliche Speicher nämlich um ein vielfaches kleiner als der Systemspeicher. Daraus folgt, dass wenn man eigene Datenverwaltung realisieren möchte, sich auch noch Gedanken über eine intelligente Caching-Strategie machen sollte. Denn 1000 Datensätze in einer linearen Liste werden sich doch wohl schon irgendwo bemerkbar machen. Zumal noch speziell Item-Eigenschaften nicht unbedingt nur gut bei den Items aufgehoben sind. Sprich, das Datenmodell wäre auch hier schon etwas starr.

Fazit: Nach meiner Meinung sind also eine Realisierung unter VB, .net und ähnlichen Umgebungen die eine exe-Datei erzeugen mit einer entsprechenden DB-Engine im Hintergrund durchaus vernünftig. Auch die Access-Version ist noch ok, verlangt allerdings eine Access-Installation.

Ach ja, Download-Link wurde aktualisiert.

 

[Alloc]

Datei-Speicher: Irgend ein Webspace Gibt doch inzwischen genug Webspace kostenlos ... da kann man dann Dateien vernünftig speichern, wenn man nix eigenes hat oder jmd kennt, bei dem man das speichern kann

Zum Prog: Da sei erstmal gesagt, dass ich bis jetzt davon ausgegangen bin, dass das ganze in VB geschrieben ist ... Scheint ja nach dem was du da geschrieben hast nicht der Fall zu sein. Heisst das, dass man mit Access derartige Oberflächen erstellen kann und auch in gewissem Umfang programmieren?

Zum Rest äußer ich mich später, wenn ich mir dein Prog erstmal angeschaut habe =)

mfG, Alloc

 

[Alloc]

Kann leider das Teil nicht starten ... nehme ja mal an, dass man dazu die Datei D2-Item-Manager.mdb öffnen sollte? Da kommt dann nämlich in Access der Fehler, der im Anhang zu sehen ist ...

Installation hatte ich ausgeführt ...

 

[Alloc]

Hm, was hast du denn da so vorzuschlagen?

Also ich habe bezüglich Programmiersprachen<->Datenbanken nur Erfahrungen in PHP+MySQL (dafür wäre das wohl aber unpassend, wie du auch schon sagtest ) und Delphi+verschiedene DB-Engines. Und da gibt es dann durchaus einiges

Noch was zu Access: Access hat die Möglichkeit, alle Datensätze einer Tabelle (oder Abfrage) in einem Endlosformular darstellen zu lassen. Man hat also alle Datensätze auf einem Schlag in einer Übersicht. Um dies auf einer anderen Plattform manuell zu realisieren, wäre ein unvergleichbar großer Mehraufwand von Nöten. Wieder ein Pluspunkt für Access.

Wie das zB bei VB ist, kann ich nicht sagen, hab unter VB noch nciht mit Datenbanken gearbeitet ... aber zumindest bei Delphi kann man (wenn man die entsprechenden Komponenten verwendet) das auch erreichen ... Habe ich aber auch noch nie gemacht, schreibe mir lieber die Anzeige für Tabellen selber, da weis ich was ich hab.

Aufgrund meines Studiums muss ich mich mit Java rumschlagen. Hätte ich mich für eine Realisierung in dieser Sprache entschieden, wäre ich vielleicht frühestens Ende des Jahres fertig. (Ich habe Mitte letzten Jahres mit der Programmierung angefangen). Hinzu kommt, dass für eine Java-Version ja immerhin keine Datenbank-Engine integriert wäre.

Klar, Java ist erstmal zu langsam und auch Umfangreich ... ich persönlich würde ein D2IM nicht benutzen, wenn er in Java geschrieben wäre. Auch weis ich nicht, ob es für Java überhaupt ordentliche DBs gibt, wobei ich meine mich zu erinnern, dass die Apache-Foundation eine DB komplett in Java entwickelt hat.

Kommen wir mal zur Datenverwaltung:
Access bringt hier schon seine eigene Datenbank mit. Würde man das unter VB programmieren, so wäre auch hier wieder der Verweis auf die Access-Engine nötig. Klar, man kann auch unter Access und Visual Basic mit ODBC-Verbindungen rumhampeln.

Wie gesagt, mit VB hab ich da auch nicht wirklich die Erfahrung, was es da gibt. Bei Delphi wird sowas aber dann wenigstens komplett einkompiliert. Meine Progs die Datenbanken nutzen haben dann außer der exe-Datei keinerlei anderen Vorrausetzungen (außer einen Windoof natürlich ).

Dementsprechend ließe sich auch schon die Freeware-Datenbank mySQL als Datenbank-Backend durchaus denkbar. Aber wie viele User wollen sich schon für so eine winzige Datenbank irgend einen SQL-Server installieren? Da könnte man ja gleich noch einen Webserver installieren, damit das ganze Programm dann in PHP entwickelt wird. Also ein bisschen viel des guten.

*Zustimm*

Bliebe noch die Möglichkeit, alles über Textdateien oder eigene Dateitypen zu machen.

Ziemlich unsinnig in der Tat ... so ein Programm hat ja doch schon relativ komplexe Zusammenhänge zwischen den verschiedenen Datensätzen ...

Fazit: Nach meiner Meinung sind also eine Realisierung unter VB, .net und ähnlichen Umgebungen die eine exe-Datei erzeugen mit einer entsprechenden DB-Engine im Hintergrund durchaus vernünftig. Auch die Access-Version ist noch ok, verlangt allerdings eine Access-Installation.

Joa, ich sehe halt vor allem den Vorteil in einem richtigen Programm mit eigener DB-Engine, dass nicht jeder Access hat (bzw die ganzen anderen Vorraussetzungen wie die OCX-Komponenten) und dass ein eigenständiges Programm auch schneller und kleiner (sowohl Binär als auch der benutzte RAM) ist.


So long, Alloc

 

[Toast78]

Bei den OCXen ist es das gleiche wie mit der Datenbank-Engine: Sie werden als Komponenten mitinstalliert.

Wenn du willst, kannst du den Source-Code bekommen

 

[Alloc]

Also habe gerade mal das Teil auf dem Lappi meiner Schwester probiert ... da kommt erst noch ein andrer Fehler (siehe Anhang) und dann der gleiche wie bei meinem Rechner...

Source-Code schadet nichts, ob das aber weiterhilft kann ich auch nicht sagen, wusste ja bis jetzt noch nicht mal, dass Access derartige Sachen kann
Aber zumindest mal anschaun...

Gruß, Chris

 

[Toast78]

Wobei tritt der Fehler auf?