Memo-Feld und MySQL-Datentyp

[MichaelE]

Hallo zusammen,

wohl wissend, dass Memo-Felder nicht gerade die wahre Option für Datenbanken
sind, benötige ich dennoch ein Feld mit der Möglichkeit, mehr als 255 Zeichen
einzugeben. Access (2000 und 2003) hat da offensichtlich nur das Memo-Feld
parat.

Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über ODBC
wieder verknüpfe habe ich das Problem, dass ich vorhandene Einträge, egal
welcher Natur, im Datensatz nicht ändern kann, ohne einen Schreibkonflikt
hervorzurufen. Wohl kann ich neue Datensätze hinzufügen. Aber schon beim
Löschen eines Datensatzes treten Probleme auf. Das System moniert einen
Schreibkonflikt, weil ein anderer Benutzer den Datensatz ebenfalls ändert.
Die Rechte in MySQL sind richtig gesetzt und auch die Parameter in Access
ermöglichen einen Multi-User-Zugriff. MySQL übenrimmt das Format als
MEDIUMTEXT. Eine nachträgliche Änderung des Datentyps in MySQL ändert nichts
an dem Problem
Verwende ich die gleiche Tabelle und formatiere dieses Feld als Textfeld mit
255 Zeichen funktioniert alles perfekt.
Frage, gibt es eine Lösung, die es mir ermöglicht, ein "MySQL-freundliches"
Datenformat zu wählen, das mehr als 255 Zeichen hat?

Vielleicht hat ja jemand schon mal Erfahrungen damit gemacht.

Danke im voraus

Michael Euler

[Josef Poetzl]

Hallo!

MichaelE schrieb:
[...]

Post by MichaelE
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über ODBC
wieder verknüpfe habe ich das Problem, dass ich vorhandene Einträge, egal
welcher Natur, im Datensatz nicht ändern kann, ohne einen Schreibkonflikt
hervorzurufen.

Welchen Datentyp verwendest du in MySQL?
Eigentlich sollten text oder z. B. varchar(2000) funktionieren.

Ich vermute das Problem eher an anderer Stelle:
Sind ein Primärschlüssel und ein Timestamp-Feld in der Tabelle
vorhanden?


mfg
Josef

[MichaelE]

Hallo Josef,

Beim Export in MySQL wurde das Memo-Feld in MEDIUMTEXT umgesetzt. Eine
nachträgliche Änderung dieses Typs in MySQL in VARCHAR 255 oder TEXT oder
LONGTEXT liefert kein anderes Ergebnis. Das Problem scheint auf der
Access-Seite zu liegen. Wenn ich die gleiche Tabelle einem Textfeld (255)
anstelle des Memo-Feldes exportiere und dann wieder verknüpfe habe ich
keinerlei Probleme. Auf der MySQL-Seite erhalte ich dann ein VARCHAR(255).
Und dies vollkommen unberücksichtigt, ob ich das ID-Feld mit einem
Präimärschlüssel versehen habe oder nicht. Ein Timestamp-Datenfeld ist nicht
vorhanden.

Ich habe das Gefühl, dass die unklare Feldlänge bei Memo (max 64000) und
TEXT (max 65535), bzw. MEDIUMTEXT mit bis zu 16 Mio Zeichen das Problem
verursacht. Ich meine, dass ich etwas Ähnliches schon mal irgendwo
aufgeschnappt habe.

Gruß
Michael Euler

Post by Josef Poetzl
Hallo!
[...]

Post by MichaelE
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über ODBC
wieder verknüpfe habe ich das Problem, dass ich vorhandene Einträge, egal
welcher Natur, im Datensatz nicht ändern kann, ohne einen Schreibkonflikt
hervorzurufen.

Welchen Datentyp verwendest du in MySQL?
Eigentlich sollten text oder z. B. varchar(2000) funktionieren.
Sind ein Primärschlüssel und ein Timestamp-Feld in der Tabelle
vorhanden?
mfg
Josef
--
EPT: (Access Error Prevention Table) http://access.joposol.com/
FAQ: (Access-FAQ von Karl Donaubauer) http://www.donkarl.com/
.

[Sascha Trowitzsch]

Hi Michael,

Post by MichaelE
Hallo zusammen,
wohl wissend, dass Memo-Felder nicht gerade die wahre Option für
Datenbanken sind, benötige ich dennoch ein Feld mit der Möglichkeit,
mehr als 255 Zeichen einzugeben. Access (2000 und 2003) hat da
offensichtlich nur das Memo-Feld parat.
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über
ODBC wieder verknüpfe habe ich das Problem, dass ich vorhandene
Einträge, egal welcher Natur, im Datensatz nicht ändern kann, ohne
einen Schreibkonflikt hervorzurufen. Wohl kann ich neue Datensätze
hinzufügen. Aber schon beim Löschen eines Datensatzes treten Probleme
auf. Das System moniert einen Schreibkonflikt, weil ein anderer
Benutzer den Datensatz ebenfalls ändert. Die Rechte in MySQL sind
richtig gesetzt und auch die Parameter in Access ermöglichen einen
Multi-User-Zugriff. MySQL übenrimmt das Format als MEDIUMTEXT. Eine
nachträgliche Änderung des Datentyps in MySQL ändert nichts an dem
Problem
Verwende ich die gleiche Tabelle und formatiere dieses Feld als
Textfeld mit 255 Zeichen funktioniert alles perfekt.
Frage, gibt es eine Lösung, die es mir ermöglicht, ein
"MySQL-freundliches" Datenformat zu wählen, das mehr als 255 Zeichen
hat?
Vielleicht hat ja jemand schon mal Erfahrungen damit gemacht.

Ich verwende LONGTEXT für die Memos.
Ich vermute aber, wie Josef, dass das Aktualisierungsproblem eher von
fehlendem Primarykey und/oder Timestamp herrührt.

Ciao, Sascha

[MichaelE]

Hallo Sascha,

habe eben auch an Josef geantwortet, daher in Ergänzung: Als ich die Tabelle
exportierte, war in der ACCess-TAbelle der Prmärschlüssel auf der ID gesetzt.
In der exportierten MySQL-Tabelle war der Primärschlüssel nicht mehr gesetzt,
ich habe ihn dann manuell in MySQL wieder auf die ID gesetzt. Spielet aber
alles keine Rolle.

Mit nachträglichem Umkonfigurieren des Feldes in der MySQL-TAbelle auf
LONGTEXT habe ich auch kein anderes Ergebnis erzielt. Eingabe neuer
Datensätze ja, bei Änderung oder Löschen bereits eingegebener Daten gibts
Probleme. (aber nur von Access aus!)

EIn LONGTEXT-Feld sollte es in Access geben

Gruß
Michael Euler

Post by Sascha Trowitzsch
Hi Michael,

Post by MichaelE
Hallo zusammen,
wohl wissend, dass Memo-Felder nicht gerade die wahre Option für
Datenbanken sind, benötige ich dennoch ein Feld mit der Möglichkeit,
mehr als 255 Zeichen einzugeben. Access (2000 und 2003) hat da
offensichtlich nur das Memo-Feld parat.
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über
ODBC wieder verknüpfe habe ich das Problem, dass ich vorhandene
Einträge, egal welcher Natur, im Datensatz nicht ändern kann, ohne
einen Schreibkonflikt hervorzurufen. Wohl kann ich neue Datensätze
hinzufügen. Aber schon beim Löschen eines Datensatzes treten Probleme
auf. Das System moniert einen Schreibkonflikt, weil ein anderer
Benutzer den Datensatz ebenfalls ändert. Die Rechte in MySQL sind
richtig gesetzt und auch die Parameter in Access ermöglichen einen
Multi-User-Zugriff. MySQL übenrimmt das Format als MEDIUMTEXT. Eine
nachträgliche Änderung des Datentyps in MySQL ändert nichts an dem
Problem
Verwende ich die gleiche Tabelle und formatiere dieses Feld als
Textfeld mit 255 Zeichen funktioniert alles perfekt.
Frage, gibt es eine Lösung, die es mir ermöglicht, ein
"MySQL-freundliches" Datenformat zu wählen, das mehr als 255 Zeichen
hat?
Vielleicht hat ja jemand schon mal Erfahrungen damit gemacht.

Ich verwende LONGTEXT für die Memos.
Ich vermute aber, wie Josef, dass das Aktualisierungsproblem eher von
fehlendem Primarykey und/oder Timestamp herrührt.
Ciao, Sascha
.

[MichaelE]

Hallo zusammen,

das Problem ist gelöst !! Die Lösung findet sich hier im Forum und zwar unter:

www.donkarl.com > Access - FAQ > 8.Kommunikation > 8.9 Access und MySQL

dort anklicken:
http://www.codekabinett.com/page.php?Theme=4&Lang=1 und >
"Grundloser Schreibfehler" auswählen.

Klasse, die Antwort liegt im TIMESTAMP-Feld. Selbisges habe ich in den
betroffenen Tabellen hinzugefügt und für dieses Feld "current timestamp"
aktiviert. Siehe da, das ganze flutscht wie ein Zäpfchen.

Besten Dank an Karl Donaubauer

Grüße
Michael Euler

Post by MichaelE
Hallo zusammen,
wohl wissend, dass Memo-Felder nicht gerade die wahre Option für Datenbanken
sind, benötige ich dennoch ein Feld mit der Möglichkeit, mehr als 255 Zeichen
einzugeben. Access (2000 und 2003) hat da offensichtlich nur das Memo-Feld
parat.
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über ODBC
wieder verknüpfe habe ich das Problem, dass ich vorhandene Einträge, egal
welcher Natur, im Datensatz nicht ändern kann, ohne einen Schreibkonflikt
hervorzurufen. Wohl kann ich neue Datensätze hinzufügen. Aber schon beim
Löschen eines Datensatzes treten Probleme auf. Das System moniert einen
Schreibkonflikt, weil ein anderer Benutzer den Datensatz ebenfalls ändert.
Die Rechte in MySQL sind richtig gesetzt und auch die Parameter in Access
ermöglichen einen Multi-User-Zugriff. MySQL übenrimmt das Format als
MEDIUMTEXT. Eine nachträgliche Änderung des Datentyps in MySQL ändert nichts
an dem Problem
Verwende ich die gleiche Tabelle und formatiere dieses Feld als Textfeld mit
255 Zeichen funktioniert alles perfekt.
Frage, gibt es eine Lösung, die es mir ermöglicht, ein "MySQL-freundliches"
Datenformat zu wählen, das mehr als 255 Zeichen hat?
Vielleicht hat ja jemand schon mal Erfahrungen damit gemacht.
Danke im voraus
Michael Euler

[Peter Doering]

Hallo,

[...]

... und in der ersten Antwort von Josef (2. Absatz ;-)

Gruss - Peter

[Sascha Trowitzsch]

Hi,

Post by Peter Doering
Hallo,

Post by MichaelE
das Problem ist gelöst !! Die Lösung findet sich hier im Forum und
zwar unter: [...]

... und in der ersten Antwort von Josef (2. Absatz ;-)

...inkl. meiner...

Ciao, Sascha

[MichaelE]

Hi Peter, Sascha und Josef

ich geb Euch Recht, natürlich habt Ihr den fehlenden Timestamp als mögliche
Ursache gesehen, nur, ich als weniger Versierter konnte mit dem Hinweis
nichts anfangen. Erst über die Erläuterung auf Karl Donaubauers Seite sind
mir die Zusammenhänge klar geworden und das ist der wirkliche Lerneffekt.
Einem Versierten hätte der Hinweis als Erinnerung gereicht, aber ein
Versierter vegisst das ohnehin nicht.

Knackpunkt ist, dass ich mich mit allen Microsoft Office-Programemn
einschließlich VBA zurechtfinden muss, neben Dreamweaver, Acrobat,
Flowcharter, MySQL, php und weiß der Teufel noch, jeder Kunde hat ein anderes
Wehwehchen und Aufgabenstellung, für das/die er eine für ihnzugeschnittene
Antwort sucht. Die muss aber so gut sein, dass er begeistert ist und ich muss
in der Lage sein, die Lösung zu beherrschen. Und genau hier für sind solche
Foren ideal, wo man auf Experten, wie Euch und die vielen anderen trifft.

Also, besten Dank für EURE Hinweise und Euer Engagement und das vieler
anderer in den Foren und in der Sache grundsätzlich. Und sorry, dass ich
etwas mehr Hintergrund benötigt habe.

Bis zum nächsten mal
Michael Euler

Post by MichaelE
Hallo zusammen,
www.donkarl.com > Access - FAQ > 8.Kommunikation > 8.9 Access und MySQL
http://www.codekabinett.com/page.php?Theme=4&Lang=1 und >
"Grundloser Schreibfehler" auswählen.
Klasse, die Antwort liegt im TIMESTAMP-Feld. Selbisges habe ich in den
betroffenen Tabellen hinzugefügt und für dieses Feld "current timestamp"
aktiviert. Siehe da, das ganze flutscht wie ein Zäpfchen.
Besten Dank an Karl Donaubauer
Grüße
Michael Euler

Post by MichaelE
Hallo zusammen,
wohl wissend, dass Memo-Felder nicht gerade die wahre Option für Datenbanken
sind, benötige ich dennoch ein Feld mit der Möglichkeit, mehr als 255 Zeichen
einzugeben. Access (2000 und 2003) hat da offensichtlich nur das Memo-Feld
parat.
Wenn ich nun die Tabellen in MySQL konvertiere, und anschließend über ODBC
wieder verknüpfe habe ich das Problem, dass ich vorhandene Einträge, egal
welcher Natur, im Datensatz nicht ändern kann, ohne einen Schreibkonflikt
hervorzurufen. Wohl kann ich neue Datensätze hinzufügen. Aber schon beim
Löschen eines Datensatzes treten Probleme auf. Das System moniert einen
Schreibkonflikt, weil ein anderer Benutzer den Datensatz ebenfalls ändert.
Die Rechte in MySQL sind richtig gesetzt und auch die Parameter in Access
ermöglichen einen Multi-User-Zugriff. MySQL übenrimmt das Format als
MEDIUMTEXT. Eine nachträgliche Änderung des Datentyps in MySQL ändert nichts
an dem Problem
Verwende ich die gleiche Tabelle und formatiere dieses Feld als Textfeld mit
255 Zeichen funktioniert alles perfekt.
Frage, gibt es eine Lösung, die es mir ermöglicht, ein "MySQL-freundliches"
Datenformat zu wählen, das mehr als 255 Zeichen hat?
Vielleicht hat ja jemand schon mal Erfahrungen damit gemacht.
Danke im voraus
Michael Euler

[Winfried Sonntag]

Post by MichaelE
ich geb Euch Recht, natürlich habt Ihr den fehlenden Timestamp als mögliche
Ursache gesehen, nur, ich als weniger Versierter konnte mit dem Hinweis
nichts anfangen.

Dann fragt man ganz einfach nach. Hier wird dich sicher niemand beissen.

Post by MichaelE
Erst über die Erläuterung auf Karl Donaubauers Seite sind mir die
Zusammenhänge klar geworden und das ist der wirkliche Lerneffekt.
Einem Versierten hätte der Hinweis als Erinnerung gereicht, aber ein
Versierter vegisst das ohnehin nicht.

Auch ein Versierter kann vergessen. Ein nicht versierter soll nachfragen
wenn er etwas nicht versteht. Aber eine angebotene Lösung ignorieren
weil man sie nicht versteht, oder nichts damit anfangen kann, ist IMHO
schlichtweg ignorant und dumm. Sorry für die harten Worte, aber das muß
mal gesagt werden.

Servus
Winfried

[MichaelE]

Hallo Winfried,

wenngleich mir die beiden Kommentare zunächst nichts sagten, sie gaben mir
dennoch Anhaltspunkte, um auf dem Weg weiterzusuchen. Foren sind m.E. nicht
dazu da, Themen immer wieder durchzukauen. Ich bin der Ansicht, dass man sich
auch über Hinweise durchsuchen sollte und erst wenn man nach angemessener
Zeit nicht fündig wird, sollte man fragen. Mit den Hinweisen von Josef und
Sascha und besonders den links, von denen Du ja auch zahlreiche aufführst,
konnte ich weitersuchen und bin dann ja auch schnell fündig geworden.
Bei Deinen Beitrag suche ich noch den konstruktiven Teil. Vornehmlich der 2
Absatz ist doch sehr fragwürdig und reichlich unzutreffend, wenn man die
Gesamtherleitung betrachtet und Vorstehendes berücksichtigt.

Servus zurück Michael

Post by Winfried Sonntag

Post by MichaelE
ich geb Euch Recht, natürlich habt Ihr den fehlenden Timestamp als mögliche
Ursache gesehen, nur, ich als weniger Versierter konnte mit dem Hinweis
nichts anfangen.

Dann fragt man ganz einfach nach. Hier wird dich sicher niemand beissen.

Post by MichaelE
Erst über die Erläuterung auf Karl Donaubauers Seite sind mir die
Zusammenhänge klar geworden und das ist der wirkliche Lerneffekt.
Einem Versierten hätte der Hinweis als Erinnerung gereicht, aber ein
Versierter vegisst das ohnehin nicht.

Auch ein Versierter kann vergessen. Ein nicht versierter soll nachfragen
wenn er etwas nicht versteht. Aber eine angebotene Lösung ignorieren
weil man sie nicht versteht, oder nichts damit anfangen kann, ist IMHO
schlichtweg ignorant und dumm. Sorry für die harten Worte, aber das muß
mal gesagt werden.
Servus
Winfried
--
KnowHow.mdb: http://www.freeaccess.de/knowhow.asp
Access-FAQ: http://www.donkarl.com/AccessFAQ.htm
Access-Stammtisch: http://www.access-muenchen.de/
Richtig zitieren: http://einklich.net/usenet/zitier.htm
.

[Winfried Sonntag]

Post by MichaelE
Bei Deinen Beitrag suche ich noch den konstruktiven Teil. Vornehmlich der 2
Absatz ist doch sehr fragwürdig und reichlich unzutreffend, wenn man die
Gesamtherleitung betrachtet und Vorstehendes berücksichtigt.

Ich zitiere mal von dir:
| ich geb Euch Recht, natürlich habt Ihr den fehlenden Timestamp als
| mögliche Ursache gesehen, nur, ich als weniger Versierter konnte mit
| dem Hinweis nichts anfangen.

Genau diese Aussage hat mich dazu gebracht, den 2. Absatz in meinem
letzten Posting zu schreiben. Wenn Du den Zusammenhang dazu nicht
verstehst, dann kann ich auch nichts mehr machen.


Servus
Winfried

[Sascha Trowitzsch]

Hi Winried,

Post by Winfried Sonntag

Post by MichaelE
Bei Deinen Beitrag suche ich noch den konstruktiven Teil.
Vornehmlich der 2 Absatz ist doch sehr fragwürdig und reichlich
unzutreffend, wenn man die Gesamtherleitung betrachtet und
Vorstehendes berücksichtigt.
ich geb Euch Recht, natürlich habt Ihr den fehlenden Timestamp als
mögliche Ursache gesehen, nur, ich als weniger Versierter konnte mit
dem Hinweis nichts anfangen.

Genau diese Aussage hat mich dazu gebracht, den 2. Absatz in meinem
letzten Posting zu schreiben. Wenn Du den Zusammenhang dazu nicht
verstehst, dann kann ich auch nichts mehr machen.

Na, nu krieg dich mal wieder ein, Winfried - ist doch halb so wild.
Man kann jemand deshalb nicht als dumm bezeichnen.

Ciao, Sascha

[Winfried Sonntag]

Post by Sascha Trowitzsch
Na, nu krieg dich mal wieder ein, Winfried - ist doch halb so wild.
Man kann jemand deshalb nicht als dumm bezeichnen.

Ist doch wahr, Hinweise ignorieren weil man sie nicht versteht, machen
bestimmt genügend. Aber das dann auch noch zu schreiben und Kritik
dazu nicht zu verstehen, das hat mir den Blutdruck nach oben
getrieben. Jetzt aber EOT dafür.

Servus
Winfried