PDA

Vollständige Version anzeigen : Lösung für Einsteigsformular


Sonja Reindl
08.10.2001, 10:20
Hallo Zusammen,

ich entwickle gerade ein Programm für die Vergabe von Sozialwohnungen. Dazu muß ich ca 2700 Häuser mit ca. 12000 Wohnungen verwalten. Nun bin ich am Hin- und Herüberlegen wie ich am vernünftigsten den Einsteig für den Anwender mache, sich das gewünschte Haus und die dazugehörigen Wohnungen oder auch nur eine Wohnung direkt anzeigen zu lassen. Eigentlich schwebt mir sowas wie der Explorer vor, aber erstes scheint mir diese TreeView-Steuerelement sehr kompliziert zu sein, zweites weiß ich nicht so recht wegen der benöitgten Lizenz und drittens hab ich irgenwo gelesen, dass es bei vielen Daten sehr langsam wird. Aber was sind "viele" Daten?
Hat jemand von Euch einen Lösungsvorschlag für mich.
Was mir auch gefallen würde, wäre oben die Eingabe des Straßennamens und in einem Unterformular werden dann die entsprechenden Daten angezeigt, wobei das Eingabefeld so ein "automatisches Ergänzen"-Verhalten wie ein Kombinationsfeld haben soll.

Ich hoffen, dass Ihr mir mit dem einen oder anderen Lösungsvorschlag weiterhelfen könnt.

Danke
Sonja

hermi
08.10.2001, 11:55
Servusla Sonja,

zum den Grenzen einer Datenbank (A 97)hat mal Dev Ashish geschrieben:

Database (.mdb) file size 1 gigabyte.

However, because your database can include linked tables in other files, its total size is limited only by available storage capacity.

Number of characters in an object name 64
Number of characters in a password 14
Number of characters in a user name or group name 20
Number of concurrent users 255
Number of characters in a table name 64
Number of characters in a field name 64
Number of fields in a table 255
Number of characters in a Text field 255
Number of characters in a Memo field 65,535 when entering data through the user interface;
1gigabyte when entering data programmatically.

Form or report width 22 in. (55.87 cm)
Section height 22 in. (55.87 cm)
Height of all sections plus section headers (in Design view) 200 in. (508 cm)
Number of levels of nested forms or reports 3
Number of fields or expressions you can sort or group on in a report 10
Number of controls and sections you can add over the lifetime of the form or report 754

Soweit zum Zitat.

Ich denke mit deinem Vorhaben stösst du noch nicht an die Grenzen von Access.

Es hängt aber viel davon ab, wie du die mdb aufbaust und 'designst'.
Du kannst ja mehrere Suchformulare erstellen, in denen nach Haus und/oder Wohnung gesucht wird. Das ist über Abfragen kein Problem. Auch von einander abhängige Kombifelder sind denkbar (Straße -> Haus -> Wohnung).

Wichtig ist die Grundstruktur und Verknüpfungen der Tabellen zu überdenken.
Lieber länger überlegt, als später eine mdb umzubasteln.

Ich würde auf Abhieb eine Tabelle mit den Häusern und eine Tabelle mit den Wohnungen, evtl. eine mit den Mietern machen und dann entsprechend verknüpfen.

Was du mit der Lizenz meinst kann ich nicht so recht nachvollziehen, denn ich gehe davon aus, dass jeder User eine Orginallizenz von M$ hat.

hth hermi

Sonja Reindl
08.10.2001, 12:10
Hallo Hermi,

also mit den Grenzen hab ich kein Problem, da es die Anwendung auch schon unter Access 2.0 gegeben hat. Nur möcht ich sie nicht einfach nur konvertieren, weil meine Access 2.0-Kenntnisse vor 8 Jahren noch bescheidener waren als meine jetzigen in Access97.

Selbstverständlich haben meine Anwender Access97-Lizenzen, ich dachte ja nur, weil ich doch für diese Active-X-Sachen die Entwicklerlizenz brauche, und die haben natürlich nicht alle.

Ich hab seperate Tabellen für Häuser, Wohnungen und Mieter,schon allein aus dem Grund weil total unterschiedliche Daten erfasst sind.

Bisher habe ich es so gelöst, dass der Anwender in ein Formular die Adresse (Straße + Hausnr. + evtl. Wohnungsnr) eingegeben hat und ich hab ihm dann den entsprechenden Datensatz angezeigt bzw. eine Meldung ausgegeben, dass es dieses Objekt nicht gibt.
Ich weiß, dass man nicht alles wegschmeissen soll, was läuft, aber das muss doch irgendwie moderner auch gehen.

Sonja

hermi
08.10.2001, 12:34
nochamol servusla,

was in A 2.0 läuft und sich die Anwender an die Bedienung gewöhnt haben, konvertiere dann doch nach A97 oder A00.
Oder lass es einfach sein. Wie sprach schon der alte Indianerhäuptling: Never touch a running System. [grins]
Wenn euch der Fortschritt in Form eines höheren Access erreicht hat, konvertieren.
Und evtl auch die User mal fragen, was sie sich bei der täglichen Arbeit mit der mdb wünschen und dann dies nach Möglichkeit umsetzen.
Bei den ActiveX-Elemente, die du einsetzen willst, geht das Registrieren über Extras -> ActiveXSteuerelemente -> aussuchen und auf registrieren klicken. Darauf acht geben, dass diegleichen bei allen Usern registriert sind. Sonst hat der eine oder andere Probleme.

hth hermi

Sonja Reindl
08.10.2001, 12:49
Hallo Hermi,

also mit den Grenzen hab ich kein Problem, da es die Anwendung auch schon unter Access 2.0 gegeben hat. Nur möcht ich sie nicht einfach nur konvertieren, weil meine Access 2.0-Kenntnisse vor 8 Jahren noch bescheidener waren als meine jetzigen in Access97.

Selbstverständlich haben meine Anwender Access97-Lizenzen, ich dachte ja nur, weil ich doch für diese Active-X-Sachen die Entwicklerlizenz brauche, und die haben natürlich nicht alle.

Ich hab seperate Tabellen für Häuser, Wohnungen und Mieter,schon allein aus dem Grund weil total unterschiedliche Daten erfasst sind.

Bisher habe ich es so gelöst, dass der Anwender in ein Formular die Adresse (Straße + Hausnr. + evtl. Wohnungsnr) eingegeben hat und ich hab ihm dann den entsprechenden Datensatz angezeigt bzw. eine Meldung ausgegeben, dass es dieses Objekt nicht gibt.
Ich weiß, dass man nicht alles wegschmeissen soll, was läuft, aber das muss doch irgendwie moderner auch gehen.

Sonja