Hilfe für Access-Newbie

[Organic]

Hallo,
Ich muss in unserer Firma die GTIN-Nummern-Verwaltung über Access 2003 machen. Nur leider hab ich von Access null Ahnung

Also ich versuch das ganze mal (hoffentlich verständlich) zu erklären:

Also ich hab in Access schon eine Tabelle mit 6 Feldern erstellt:

ID - GTIN - Artikelnummer - Bezeichnung - Serie - Dekor

Beispiel:
4050265403951 - 4912491944885106 - Becher mit Henkel stapelbar 0,26l - Swing Time - 5 mm Band Colour gelb


Insgesamt hab ich 10.000 GTIN-Nummern zu verfügung. Nicht jede ist vergeben, zur Zeit ca 500.


Jetzt soll ich das so machen, das man in einem Formular, gleich die erste Freie GTIN-Nummer sieht und die weiteren Daten eintragen kann.

Wie kann ich das am besten machen?
Außerdem soll Access doppelte GTIN- und Artikelnummern vermeiden bzw erkennen.

Falls ihr Fragen habt, fragt einfach und ich versuch sie so gut wie es geht zu beantworten

 

[little_skunk]

Falls ihr Fragen habt, fragt einfach und ich versuch sie so gut wie es geht zu beantworten

Eine Frage habe ich. Warum legst du einen zusätzlichen Primärschlüssel (ID) an, wenn du doch bereits einen Primärschlüssel vorgegeben hast? Damit würden sich deine 2 Probleme erübrigen. Im Formular würde automatisch die nächste freie Nummer angezeigt werden und doppelt vergeben ist auch nicht möglich.

 

[blitzkid]

also...
wenn "gtin" eindeutig einer zeile gehört.. würd ich das spontan als schlüssel nehmen...

 

[little_skunk]

würd spontan sagen dass access das nicht kann...

Falsch geraten. Access kann das. Dafür muss es sich aber um einen Autowert handeln, der von alleine hochzählt.

Edit: Jetzt hast du es schon rauseditiert. Ich habs trotzdem mitbekommen

 

[blitzkid]

jow... habs bei dir gelesen somit wars überflüssig... hatte nur im hinterkopf das access in manchenfällen bissel beschrenkt ist wenns um bedinunngen und co geht...

ich hatte bis jetzt eher in sap systemen gearbeitet^^

 

[little_skunk]

Ich bevorzuge auch Oracle keine Frage. Access ist sicherlich nicht gerade das schönste Programm aber das vorliegende Problem hat weniger mit Access zu tun als mehr mit Datenbankdesign.

So beschränkt ist Access garnicht. Hab das auch immer gedacht aber nachdem ich letztens ein Projekt in Access umgesetzt habe, war ich doch überascht was ich alles einbauen konnte. Vieles natürlich nur über VBA aber es ist möglich. Der große Nachteil an Access ist eigentlich nur die fehlende Mehrbenutzerfähigkeit und damit verbunden das (fehlende bzw unzureichende) Rechtesystem.

 

[passat3233]

Access ist sehr wohl Mehrbenutzerfähig und es gibt auch ein Rechtesystem.
Allerdings ist das Rechtesystem rel. beschränkt und um es halbwegs sicher zu bekommen, braucht es schon ein wenig Arbeit.
Ich habe schon Access-Projekte (z.B. Warenwirtschaft, im Produktiveinsatz seit über 10 Jahren) gemacht, mit denen 20 Leute gleichzeitig arbeiten.
Bei einer größeren Anzahl an Leuten (mehr als ca. 15-20) sollte man als Backend allerdings nicht die Jet-Datenbank von Access nehmen, sondern z.B. Oracle oder einen SQL-Server, da ab einer bestimmte Benutzeranzahl die Jet-Datenbank rel. langsam wird.
Access spielt dann nur Benutzeroberfläche, aber das geht prima.

 

[little_skunk]

Damit hast du meine Aussage doch 100% bestätigt. Access ist nicht Mehrbenutzerfähig. Ich rede dabei von 1000 Anwender, die gleichzeitig auf eine Datenbank zugreifen. Access kann das schlichtweg nicht. Das Rechtesystem ist wie du schon sagst einfach nur unzureichend. Der Anwender kommt trotzdem an die Daten ran, wenn die Accessdatenbank auf seiner Festplatte abgelegt ist.
Warum sollte ich Access als Frontend verwenden? Dann kann ich auch gleich Java oder VB.Net verwenden, wenn das Backend bereits eine Oracle oder MySQL Datenbank ist.

So genug über Access hergezogen. Was ist jetzt aus dem Problem geworden? Hat sich das schon erledigt?

 

[passat3233]

Das Rechtesystem ist wie du schon sagst einfach nur unzureichend. Der Anwender kommt trotzdem an die Daten ran, wenn die Accessdatenbank auf seiner Festplatte abgelegt ist.

Man kann ihm das aber extrem erschweren:
- Datenbankverschlüsselung aktivieren, dann kann man die Daten nicht mehr im Klartext in einem Editor ansehen
- Arbeitsgruppendatei anpassen: Besitzer aller Objekte darf NICHT der Standardbenuter Administrator oder die Gruppe Administratoren sein. Außerdem muß man dem Administrator und der Gruppe Administratoren alle Rechte wegnehmen, auch auf die DB selbst.
Schon bekommt man mit einer Standard-Arbeitsgruppendatei keinen Zugriff mehr auf die DB.
Vorher natürlich einen neuen Benutzer in einer neuen Benutzergruppe anlegen, der Besitzer aller Objekte und der BB ist und darauf Vollzugriff hat.
- In der Arbeitsgruppendatei, die man dem Kunden mitliefert, muß der Besitzer der Objekte und dessen Benutzergruppe gelöscht sein.

Zu Java: Scharchlahm, selbst auf einem 3 GHz Quadcore ist das sehr deutlich langsamer als VB auf einem 2 GHz Dualcore.
Zu VB.Net: Das gabs vor 10 Jahren noch nicht
Außerdem ist der Formular- und Berichtsentwurf bei Access doch einfacher.

 

[little_skunk]

Man kann ihm das aber extrem erschweren:
- Datenbankverschlüsselung aktivieren, dann kann man die Daten nicht mehr im Klartext in einem Editor ansehen
- Arbeitsgruppendatei anpassen: Besitzer aller Objekte darf NICHT der Standardbenuter Administrator oder die Gruppe Administratoren sein. Außerdem muß man dem Administrator und der Gruppe Administratoren alle Rechte wegnehmen, auch auf die DB selbst.
Schon bekommt man mit einer Standard-Arbeitsgruppendatei keinen Zugriff mehr auf die DB.
Vorher natürlich einen neuen Benutzer in einer neuen Benutzergruppe anlegen, der Besitzer aller Objekte und der BB ist und darauf Vollzugriff hat.
- In der Arbeitsgruppendatei, die man dem Kunden mitliefert, muß der Besitzer der Objekte und dessen Benutzergruppe gelöscht sein.

Oder anders ausgedrückt. Access hat so gut wie kein Rechtesystem. Du schreibst es schon richtig. Du kannst es dem Anwender (extrem) erschweren. So schwer wie du glaubst ist es allerdings nicht mal. Mit wenigen Handgriffen (mehr als ohne Absicherung) ist es immernoch möglich an die Daten ranzukommen. Kennst du das Rechtesystem von Oracle überhaupt? Falls nein kann ich dir gern erklären was ein richtiges Rechtesystem bei einer Datenbank so alles beinhalten sollte. Dabei geht es noch nicht mal darum, dass der Anwender an die Daten nicht rankommt sondern auch darum welche Daten er wie verändern darf. Von Triggern und Stored Procedures will ich lieber garnicht erst anfangen. Die haben zwar nichts mit dem Rechtesystem zu tun aber bieten in Zusammenarbeit mit dem Rechtesystem ungeahnte Möglichkeiten.

Zu Java: Scharchlahm, selbst auf einem 3 GHz Quadcore ist das sehr deutlich langsamer als VB auf einem 2 GHz Dualcore.

Assembler ist auch schneller als VB und? Du vergleichst da gerade Äpfel mit Birnen. Java ist annähernd genausoschnell wie VB.Net. VB lässt sich mit beiden nicht verlgeichen. VB ist keine objektorientierte Programmiersprache.

Für ein Formular, dass auf eine Datenbank zugreift, spielt die Performance aber keine Rolle.

Zu VB.Net: Das gabs vor 10 Jahren noch nicht
Außerdem ist der Formular- und Berichtsentwurf bei Access doch einfacher.

Sowohl Java als auch VB.Net bieten Frameworks, mit denen man ein Formular genauso einfach erstellen kann. Das Framework bietet einem alle Daten der Tabellen an genauso wie es bei Access auch der Fall ist. Einfach nur noch das Feld aufs Formular ziehen und schon ist man Fertig.

Weil es vor 10 Jahren kein VB.Net gab, darf man es heute nicht verwenden?

Nochmal zum Mitschreiben. Access hat durchaus seine Einsatzgebiete aber es ist nunmal weder Mehrbenutzerfähig (1000 Anwender und mehr) noch hat es ein vernünftiges Rechtesystem und gilt damit nicht als Datenbank. Transaktionen sind meines Wissens in Access auch nicht möglich. Warum bietet Microsoft wohl einen extra SQL Server an?

Wir kommen damit aber immer weiter vom Thema ab. In diesem Sinne würde ich dir einfach mal das Rechtesystem einer richtigen Datenbank ans Herz legen. Bei VB.Net wird das Framework bereits mit der neusten Entwicklungsumgebung mitgeliefert. Bei Java kenn ich 2 Frameworks (leider gerade nicht namendlich), die ein solches Formular mit wenig Aufwand ermöglichen. Sollte mit google schnell zu finden sein. Danach kann jeder für sich selbst entscheiden, ob er noch Access weiterverwendet oder vieleicht doch eine Alternative wählt.

 

[passat3233]

Klar ist Assembler schneller als VB, aber Java ist das mit Abstand langsamste, was mir in den letzten 20 Jahren untergekommen ist.

Ich behaupte auch nicht, das Access für eine große Nutzerzahl geeignet wäre.
Aber es ist dennoch eine Datenbank.
Oder ist z.B. ein Smart kein Auto nur weil es einen Maybach gibt?

Was Transaktionen angeht:
Auch das kann Access.
Schau einfach mal in die Hilfe und suche nach den Befehlen Transaction, BeginTrans, CommitTrans etc.

Auch ist es sehr wohl objektorientiert.
Du kannst da rel. einfach Klassenmodule schreiben und verwenden etc.

Für kleine Projekte mit 5-10 Benutzern ist ein SQL-Server oder Oracle wohl sehr überdimensioniert. Da reicht Access locker aus.

 

[little_skunk]

Klar ist Assembler schneller als VB, aber Java ist das mit Abstand langsamste, was mir in den letzten 20 Jahren untergekommen ist.

Die Aussage ist komplett falsch. Das langsamste was dir in den letzten 20 Jahren untergekommen ist? Schau dir erstmal an was Java ausmacht und wofür man es verwendet. Wie schon geschrieben, kannst du Java nur mit anderen objektorientierten Programmiersprachen vergleichen. Java ist 99% Objektorientiert. Das trifft nur auf wenige andere Programmiersprachen zu. Somit ist Java eine der wenigen objektorientierten Programmiersprachen und ist im Vergleich nicht langsamer aber auch nicht schneller.

Ich behaupte auch nicht, das Access für eine große Nutzerzahl geeignet wäre.
Aber es ist dennoch eine Datenbank.
Oder ist z.B. ein Smart kein Auto nur weil es einen Maybach gibt?

Das kommt auf die Definition an. Ein Auto hat 4 Räder und einen Motor. Der Smart ist also ein Auto. Ist ein Moped ein Auto? Natürlich nicht! Access ist keine Datenbank, da entscheidenen Eigenschaften fehlen. Dazu ein Auszug aus Wikipedia:

Die wesentlichen Eigenschaften eines Datenbankmanagementsystems lassen sich wie folgt beschreiben:

1. Speichern der Daten
2. Verwaltung der Metadaten
3. Datensicherheit
4. Mehrbenutzerbetrieb durch Transaktionen
5. Sicherstellen der Datenintegrität
6. Anfrageoptimierung
7. Bereitstellen von Indizes
8. Bereitstellung von Triggern
9. Stored Procedures

3, 6, 8 und 9 sind nicht gegeben. Punkt 4 lässt sich drüber streiten. Wir können uns jetzt gern noch über den Rest streiten aber da Punkt 3 so oder so flach fällt, ist Access so oder so keine richtige Datenbank.

Was Transaktionen angeht:
Auch das kann Access.
Schau einfach mal in die Hilfe und suche nach den Befehlen Transaction, BeginTrans, CommitTrans etc.

Gut zu wissen. Andererseits muss eine Datenbank immer mit Transaktionen arbeiten. Meinetwegen mit Autocommit aber im Falle eines Absturzes, dürfen nicht die Hälfte der Daten verändert worden sein und die andere Hälfte nicht. In diesem Sinne ist auch Punkt 5 nicht voll erfüllt. Eine Datenbank muss jeden Updatebefehl über eine Transaktion absichern.

Auch ist es sehr wohl objektorientiert.
Du kannst da rel. einfach Klassenmodule schreiben und verwenden etc.

Ist es nicht. Auch hier gibt es eine Definition, die von VBA? nicht erfüllt wird. Die Möglichkeit Klassenmodule anzulegen reicht da nicht aus. Zum Vergleich: In Java musst du mit Klassen arbeiten.

Für kleine Projekte mit 5-10 Benutzern ist ein SQL-Server oder Oracle wohl sehr überdimensioniert. Da reicht Access locker aus.

Ich sehe du verstehst meine Kernaussage. Wobei ich die Grenze aber tiefer anlegen würde. Solange man die Daten nur alleine anschaun will, kann man Access verwenden. Ab 2 Benutzer sollte man über MySQL nachdenken. Oracle und andere kostenpflichtige Datenbanken sind erst bei großen Projekten sinnvoll. Für alles andere ist MySQL völlig ausreichend und ist dann auch nicht überdimensioniert. Nochmal. Access ist weder Mehrbenutzerfähig noch hat es ein Rechtesystem (das einer Datenbank würdig ist). Soll jeder für sich selbst entscheiden, ob er Access verwendet.

Sei mir nicht böse aber das geht hier definitiv in die Falsche Richtung. Bleib du ruhig bei Access und verzichte auf Java. Ich werd hier nicht weiter auf die Definition von Objektorientiert und Datenbank eingehen. Ich will nur die Alternativen aufzeigen. Es gibt wie gesagt Frameworks für VB.Net und Java. Das kann jeder, der möchte, einfach mal ausprobieren.

 

[passat3233]

Dann wäre nach deiner Definition z.B. MS-DOS oder Windows 9x/ME auch kein Betriebssystem, da ihm Punkt 5 fehlt.
Das bietet erst Windows NT/2000/XP etc., wenn man NTFS verwendet oder z.B. Unix, Linux etc.

 

[little_skunk]

Die wesentlichen Eigenschaften eines Datenbankmanagementsystems lassen sich wie folgt beschreiben:

Dann wäre nach deiner Definition z.B. MS-DOS oder Windows 9x/ME auch kein Betriebssystem, da ihm Punkt 5 fehlt.

Irgendwas passt da nicht so recht zusammen...