collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 57
  • Punkt Versteckte: 0
  • Punkt Mitglieder: 1
  • Punkt Benutzer Online:

* Forenstatistik

  • stats Mitglieder insgesamt: 13808
  • stats Beiträge insgesamt: 64124
  • stats Themen insgesamt: 8674
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 16
  • stats Am meisten online: 415

Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
Tabelle/Abfrage / Re: Formular in Registersteuerelement
« Letzter Beitrag von Beaker s.a. am Heute um 16:25:58 »
Hallo,
Zitat
und das ist scheinbar nicht mehr "ansprechbar".
Doch, es liegt nur noch eine Stufe tiefer.
HFo.ErsteEbeneUFoControl.Form.ZweiteEbeneUFoControl.Form.ControlDeinerWahlgruss ekkehard
2
Sonstige Datenbanken / Re: Postgresql Datentyp TIME in Access via ODBC
« Letzter Beitrag von Lachtaube am Heute um 14:41:15 »
Bitte keine Cross-Postings absetzen.
3
Access-Hilfe / Re: Preisvergleich mit Einkaufspreisen
« Letzter Beitrag von Manuel_Kraus am Heute um 14:37:46 »
Hallo Lachtaube,

sieht gut aus, nachdem ich die Abfragen nach und nach gestaltet habe, kam der innerjoin die pzn betreffend vorher mit dazu
und zum Schluß der leftjoin für den EK.
Super, vielen Dank!
4
Sonstige Datenbanken / Postgresql Datentyp TIME in Access via ODBC
« Letzter Beitrag von nowAG am Heute um 13:51:18 »
Hallo,
ich habe Probleme beim Zeit-Datentyp von Postgresql (TIME) in der Darstellung und Eingabe im Access-Formular.
Wir speichern die Uhrzeit und Tag in 2 seperaten Feldern. In Access wird der  Postgresql-Datentyp TIME immer mit dem vorangestellten aktuellem Tag dargestellt:
aus "08:00" wird am "15.01.2018 08:00". Das Ungünstige ist dabei, das am Tag darauf wiederum der aktuelle TAg dargestellt wird: "1&.01.2018 08:00":
Das Steuerelement ist schon mit den typischen Formaten belegt worden (12-Std / 24-Std-Anzeige), sowohl als Darstellungsformat, als auch als Eingabemaske.  Dargestellt wird schön nur die Uhrzeit. Klickt der Benutzer jedoch in das Steuerelemnt wechselt die Darstellung zu der Tagesdarstellung.
Wir benutzen Access 2010 (in Access 2016 tritt der Fehler auch auf) und binden die Tabelle über den aktuellsten ODBC-Postgres-Treiber aus einer Postgres DB Version 10.1 ein.

LG
Uwe
5
Formular / Re: Gruppierung, Anzahl und Anzeige
« Letzter Beitrag von Andreas_80 am Heute um 13:19:40 »
Zitat
Was soll man mit einer solchen Aussage anfangen? Wenn Du auf diesem Niveau verharren willst, dann solltest du Aufgaben mit einem höheren anspruch vermeiden.
soll heißen das ich mich erst seit einiger Zeit mit Accsess beschäftige und damit noch schwierigkeiten habe.
auf diesem Niveau verharren??? Nein
"Wer immer nur das macht was er kann, wird immer nur das bleiben was er ist."

Zitat
Praktikabel wäre aber eher ein zusätzliches abhängiges Kombinationsfeld, das in Abhängigkeit der PLZ-Auswahl die entsprechenden Kunden anzeigt.
Ich denke das wäre eine Lösung die ich versuchen werde zu realisieren. Danke
6
Access Programmierung / Re: SQL in VBA schneidet String ab
« Letzter Beitrag von Frithjiof am Heute um 12:58:37 »
Hallo Jürgen,
In der Abfrage funktioniert das auch problemlos und die Anzeige in einem UFO, das auf der Abfrage basiert, auch.

Eben, das ist im Normalfall kein Problem

Ich wollte es bloß anders machen, weil ich beim Öffnen anderer Formulare im ganzen ein Problem mit zuviel aktiven Recordsets hatte.

Ja und da stellt sich die Frage, was genau machst du anders.
Hier im Forum kann dir nur geholfen werden, wenn wir sehen können was du machst.

Leere Zeichen sind sicherlich nicht enthalten. Das habe ich geprüft.

Was willst du damit sagen? Leere Zeichen = Leerzeichen? sind auch in Access erlaubt.

Ich denke, es ist wirklich der Bug von Microsoft.
Abgesehen davon, dass es sich m.E. nicht um ein Bug handelt, sondern um einen Schutz, scheint es nicht zu stimmen, denn DF6GL hat oben festgestellt, dass der fragwürdige String mehr als 255 Zeichen enthält.

Ich hatte es spaßhalber mal probiert das Feld "Titel" in der Abfrage mit Left() und Right() zusammenzusfassen. Das klapplt bei langen Titeln bei Left(); bei Right() bringt er einem scheinbar zufällige Zeichen irgendwo aus dem String (zumindest konnte ich keine Systematik erkennen).

Die Funktionen Left() und Right()  geben ganz "systematisch" die Anzahl Zeichen zurück, die angefordert werden.
right(titel,4) gibt die 4 rechten Zeichen des Strings Titel zurück
left(titel,4) gibt die 4 linken Zeichen des Strings Titel zurück
mid(titel,2,4)  gibt die 4 Zeichen ab Position 2 des Strings Titel zurück
Nix mit voodoo ;)

Ganz generell: bei manchen Einsatzzwecken lassen sich Memofelder bzw. Felder mit langen Texten nicht umgehen. Jedes CMS ist eine Datenbank und hat Felder mit langen Texten, weil manchen Texte nunmal lang sind und nicht mehr aufgegliedert werden können. Access ist dann dann vielleicht nicht das richtige System.

Access hat kein Problem mit Memofeldern. Nur der Umgang mit ihnen ist etwas anders als mit anderen Feldern.
Nehmen wir an in einer DB existieren 100.000 Berichte=Memofelder mit jeweils ca. 3.000 Zeichen.
Um letzteres Feld zu gruppieren, also alle doppelten Berichte zusammenzufassen, müssten im schlimmsten Fall ca. 5  Mrd. mal  3.000 Zeichen miteinander verglichen werden. Da sind dann selbst moderne Rechner etwas beschäftigt.

Also: Wenn es notwendig sein sollte Felder zu Strings zu verknüpfen, macht man das am Besten am Ende der multiplen Aktionen.
Abfragen sollten so gestaltet werden, dass arbeitsaufwendige, also zeitaufwendige Operationen nur mit den Daten durchgeführt werden auf die es letztlich ankommt.  Es ist unökonomisch alle „Titel“ von allen Herausgebern oder Autoren zusammenzusetzten, um am Ende nach „Günter Grass“, oder Jahrgang 2010 zu filtern.

Frithjof
7
Formular / Re: Gruppierung, Anzahl und Anzeige
« Letzter Beitrag von ebs17 am Heute um 12:35:03 »
Zitat
Denkt bitte dran ich bin immer noch ein voll noob
Was soll man mit einer solchen Aussage anfangen? Wenn Du auf diesem Niveau verharren willst, dann solltest du Aufgaben mit einem höheren anspruch vermeiden.
Zitat
ich dann sehen kann welche Kunden zu der Gruppierten PLZ gehören
In einer dritten berechneten Spalte könnte man das lösen, allerdings wird bei 1.000 aneinander gereihten Namen die Übersicht bzw. auch die Möglichkeit der Darstellung aussteigen.

Das Zusammensetzen der Namen würde ich mit ADOConcatColumn umsetzen.

Praktikabel wäre aber eher ein zusätzliches abhängiges Kombinationsfeld, das in Abhängigkeit der PLZ-Auswahl die entsprechenden Kunden anzeigt.
8
Tabelle/Abfrage / Re: Parameterwert eingeben
« Letzter Beitrag von MzKlMu am Heute um 11:58:50 »
Hallo,
die Antwort verstehe ich nicht ganz.
Zitat
Wenn das Zertifikat einmal ausgeteilt ist, dann nicht. Aber sonst natürlich laufend während der Schulzeit.
Es gibt also mehrere Zertifikate während der Schulzeit ?
Wenn ja, fehlt noch eine Tabelle zur Erfassung der Zertifikate. Was dann aber wieder einen anderen Aufbau der Beziehungen erfordert.
Bitte erkläre das mit den Zertifikaten mal genauer. Das ist wichtig, denn davon hängt der Aufbau ab.
9
Formular / Gruppierung, Anzahl und Anzeige
« Letzter Beitrag von Andreas_80 am Heute um 11:56:33 »
Guten Tag,

komme mal gleich zum Punkt.

Erstelle gerade eine Statistik, wieviele Kunden ("Vorname" und "Name") mit der selben PLZ gibt es?
Soweit ganz toll alle PLZ werden Gruppiert und in einer zweiten Spalte "Anzahl" steht auch eine Zahl wie viel PLZ es tatsächlich sind.

Ich möchte nun in meinem Formular eine Art Dropdown haben ob in einer der beiden Spalten (PLZ, Anzahl) oder einer dritten, in der ich dann sehen kann welche Kunden zu der Gruppierten PLZ gehören.
Wie sollte ich das denn am besten bzw. einfachsten realisieren. Denkt bitte dran ich bin immer noch ein voll noob
Danke für die die Hilfe. :-)
10
Access Programmierung / Re: SQL in VBA schneidet String ab
« Letzter Beitrag von ebs17 am Heute um 11:52:44 »
Zitat
die Daten ... werden dann erst für die Gesamtausgabe des Titels über mehrere Abfragen zusammengestellt
In diesem Prozess können auch Reserven + Probleme liegen. Statt einen Ablauf als gegeben hinzunehmen könnte man ihn auch auf den Prüfstand stellen.

Zitat
bei manchen Einsatzzwecken lassen sich Memofelder bzw. Felder mit langen Texten nicht umgehen
Das steht außer Frage. Aber man muss nicht zwingend lange Texte in Abfragen hin- und herschieben, schon weil das mal Datenmasse ist. Das Hin- und Herschieben kann man regelmäßig über eine entsprechende ID erledigen, und den Text holt man sich dann zur Anzeige nach den Verarbeitungen.

Zur Kritik an der Entwicklungsumgebung darf man auch immer etwas Selbstkritik hinzufügen.
Seiten: [1] 2 3 ... 10