Office: (Office 2003) Chinesische Zeichen als Abfrageergebnis

Ja, Long Integer, Auto in beiden Textfeldern.

 

Ja, Long Integer, ohne Angabe des Zahlenformats (Standardzahl, Allgemeine Zahl etc.), Dezimalstellen: Automatisch bei beiden Feldern.

 

Hallo
kannst Du mir eine Muster MDB gezipt hochladen ?¨

MusterMDB = nötige Tabelle,Abfragen, Formulare etc.
in den Tabellen einige muster DS(Datensätze) nicht Original(scharfe) Daten

ich möchte das mir Ansehen *wink.gif*

 

Würde Dir die DB gerne schicken. Sind keine "sensible" Daten drin. Gezippt ist die jedoch immer noch ca. 10 MB. Abspecken ist etwas komplex, da ich nicht weiß, was alles gebraucht wird und Verkleinerung der Datenmenge in den Tabellen bringt nicht viel. Kann ich Dir das als Mail oder per Filemail schicken?
Mein e-Mail Adresse ist [Edit] Mof-Team AD: Mailadresse entfernt [/Edit]
Falls Du eine Lösung findest würden wir das natürlich dem Forum mitteilen. Ich möchte nicht, dass das dann am MOF vorbei geht.

 

Hallo
werde Heute nach 18:00 mir das zu gemühte führen *wink.gif*

p.s grosse Dateien kann man gut über Skype versenden
aber ich habe sie ja.

 

Hallo Ruedi,

nach einigem Hin- und Her habe ich einen "Workaround" gefunden, der die Ausgabe von korrekten Zahlen in der Anfügeabfrage ergibt. Ursprünglich hatte ich ja zur Erzeugung der Masterkeys in der Untertabelle folgenden String in die Abfrage geschrieben:
"Masterkey: [Formulare]![Aufnahmen]![Key]"
wobei "Key" die Zahl ist, über die die Datensätze der Untertabelle mit einem DS der Mastertabelle verknüpft sind. Die Abfrage lieferte jedoch asiatische Schriftzeichen (das war der Ausgangspunkt meines Beitrags in diesem Thread).

Durch Zufall ergänzte ich beim "Rumspielen" diesen String folgendermaßen:
"Masterkey: [Formulare]![Aufnahmen]![Key]+0"

also ich addierte "Null" zu dieser Zahl. Danach wurden die Zahlen korrekt ausgegeben.

Es wird ein Rätsel bleiben. Ich wundere mich ja sowieso schon lange, warum es so umständlich ist, Datensätze zusammen mit verknüpften DS einer verknüpften Tabelle zu kopieren. Das ist doch ein Vorgang, der nicht so selten gewünscht wird - oder?

Jedenfalls Dir vielen Dank für Deine Zeit und herzliche Grüße an alle MOF-Freunde.

Friedhelm

 

Hallo
schön das Du den Fehler selber gefunden hast *Smilie *top

im Angesich der GRÖSSE Deiner MDB noch einiges was ich dir sehr epfehlen möcht zu machen

1. mach ein FE / BE Lösung (Aufteilen in Programteil (FE) Daten teil (BE)Lies in Meine Doc (in meiner Fusszeile auf Seite 38)
2. lies auf Seite 61Bei der Datenherkunft bei Formularen, Berichten, (Kombifelder etc.) wenn möglich Nicht als
SQL-string angeben sonder diesen SQL speichern als Abfrage
diese währen zu korigieren:

3. Lies ab Seite 57 das ganze Kapitel 5.2 bis Seite 65
eigendlich solltest Du alles was da geschrieben steht berücksichtigen (einbauen)
mach evtl. auch einmal ein Decompile lies bei Donkarl donkarls Access-Seiten
nur mit Kopie der MDB arbeiten.
gehe ungefähr so vor :
Extra/Analyse/Leistung über Alle objekte / Alle auswählen und laufen lassen evtl. korrekturen vohrnehmen
• automatische Komprimieren ausschalten
• Extra/Analyse/Leistung über Alle objekte / Alle auswählen und laufen lassen evtl. korrekturen vohrnehmen
• dann die MDB Deecompilieren s. Donkarl 1.23 ( www.donkarl.com?FAQ1.23 )
• danach wieder Compileren und Reparieren – Komprimieren
• evtl. mit JETCOMP.exe Reparieren – Komprimieren JETCOMP kann man von MS runterladen.

 

Danke Ruedi für Deine ausführlichen Empfehlungen.

Was Punkt 1 mit den Empfehlungen bzgl SQL angeht, macht mich das allerdings etwas stutzig, da ich nie nie nie etwas mit SQL am Hut hatte. Ich habe immer nur die eingebauten Funktionen von Access verwendet (angefangen mit A97, vor kurzem alle DBs nach A03 konvertiert). Für SQL fehlt mir einfach die entsprechende Bildung und Geduld, mich mit dieser "benutzerfreundlichen" Syntax auseinanderzusetzen. Was Access da im Hintergrund mit meinen Abfragen gemacht hat, bewegt sich weit außerhalb meines Horizonts.

Diese Plattendatenbank ist ein Beispiel für die Komplexität meiner ca. 30 DBs, die ich bisher erstellt habe. Sie sind alle im Laufe von Jahren gewachsen, laufen aber alle ohne Probleme, wenn man mal von solchen irrationalen Bugs absieht, wie der mit den chinesischen Zeichen und anderen, bei denen mir die MOF-Gemeinde schon oft geholfen hat.

Die Empfehlungen des Access-Leistungsanalyzers habe ich mir ein paarmal angeschaut und - ehrlich gesagt - für ziemlich daneben gefunden, oder sagen wir besser für nicht wirklich hilfreich. Dass einige Formulare zu viele Steuerelemente enthalten ist mir schon klar, hat aber bisher noch nie ein Problem verursacht. Möglicherweise sind auch einige Daten redundant und entsprechen nicht den Regeln einer rationalen DB. Aber mir schien es eine gute Idee, möglichst wenig verknüpfte Tabellen zu haben, da es damit offenbar schon mal Probleme gibt, wenn man z. B. schon bei einer Verrenkungen machen muss, um Daten der verknüpften Tabelle mit zu kopieren.

Den Vorteil einer BE/FE -Lösung sehe ich nicht so recht, da ich der einzige User bin und die DBs nicht in einem Netzwerk betrieben werden. Die beiden zugrundeliegenden Tabellen bzw. die Grundstruktur der DB sind/ist ja eigentlich primitiv - oder? Ok, die Unmenge an Formularen und Abfragen ist schon ziemlich beachtlich...

Da ich einen ziemlichen Horror habe, wegen Schlamperei bei der Datensicherung die Arbeit von Jahren noch einmal neu machen zu müssen, habe ich mir schon lange angewöhnt, immer mindesten zwei Sicherheitskopien aller Datenbanken zu haben. Das hat mich schon oft genug gerettet...

Werde mich mit den Informationen auf Donkarls Seiten beschäftigen. Davon kann ich nur profitieren.

Nochmals danke für Deine Mühe.

Mit herzlichen Grüßen
Friedhelm

 

Hallo

bei Dir jetzt hier NUR das die MDB ( FE-MDB ) kleiner wird da die Daten dann die Daten in der BE_MDB sind, spielt keine rolle wenn Beide Lokal sind.
ist dan auch besser für die Sicherung der Daten *wink.gif*

 

Ok, das leuchtet ein;-)