Re: [otrs-de] tabelle xml_storage zu breit mit utf8?

2012-06-14 Diskussionsfäden Andreas Laut

Erstmal danke für das befassen mit dem Problem.
Solche Lösungen habe ich ja auch gefunden, weswegen ich dann mal die 
Varchars der xml_storage Tabelle kleiner gemacht hatte.
Das hat mein Problem gelöst und ich konnte den Dump einspielen - kam 
vielleicht nicht so klar rüber.
Ich weiß halt nicht und das war meine eigentliche Frage, ob die 
kleineren Spalten ein Problem sein könnten? Vorallem, wenn in der 
xml_storage.xml_key nur Zahlen stehen, verwundert ein 250er Varchar 
schon etwas.


Gruß
Andreas

--
Andreas Laut | Administration | 5 POINT AG
Tel.: +49 (0) 6151 13097 26 | Fax.: +49 (0) 6151 13097 10
E-Mail: andreas.l...@5point.de

5 POINT AG
Saalbaustraße 27 | 64283 Darmstadt
Tel.: +49 (0) 6151 13097 0 | Fax.: +49 (0) 6151 13097 10
E-Mail: i...@5point.de
Internet: www.5point.de | www.teamspace.de | www.projectfacts.de
Vorstand: Thorsten Lenk, Martin Fischer
Aufsichtsratvorsitzender: Prof. Dr. Horst Geschka
Sitz Darmstadt HRB: 76 27


Am 14.06.2012 16:27, schrieb Martin Gruner:

Hi Andreas,

hilft das vielleicht?

http://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes

Am 14.06.12 16:04, schrieb Andreas Laut:

ERROR 1071 (42000) at line 3347: Specified key was too long; max key
length is 1000 bytes

-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de


Re: [otrs-de] tabelle xml_storage zu breit mit utf8?

2012-06-14 Diskussionsfäden Martin Gruner
Hi Andreas,

hilft das vielleicht?

http://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes

Am 14.06.12 16:04, schrieb Andreas Laut:
> ERROR 1071 (42000) at line 3347: Specified key was too long; max key
> length is 1000 bytes

-- 
Martin Gruner
Senior Developer R&D

OTRS AG
Europaring 4
94315 Straubing

T: +49 (0)6172 681988 0
F: +49 (0)9421 56818 18
I:  www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: 
DE256610065
Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann 
(Vorsitzender), Christopher Kuhn

Verbinden wir uns! OTRS 3.1 schafft einfachere Integration mit 
Drittapplikationen – Für Frühbucher zum Vorzugspreis: 
http://www.otrs.com/index.php?id=2361&L=1



-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de


Re: [otrs-de] tabelle xml_storage zu breit mit utf8?

2012-06-14 Diskussionsfäden Andreas Laut

Hallo Martin,

ERROR 1071 (42000) at line 3347: Specified key was too long; max key 
length is 1000 bytes

In line 3347 steht /CREATE TABLE `xml_storage` (/

Gruß
Andreas

--
Andreas Laut | Administration | 5 POINT AG
Tel.: +49 (0) 6151 13097 26 | Fax.: +49 (0) 6151 13097 10
E-Mail: andreas.l...@5point.de

5 POINT AG
Saalbaustraße 27 | 64283 Darmstadt
Tel.: +49 (0) 6151 13097 0 | Fax.: +49 (0) 6151 13097 10
E-Mail: i...@5point.de
Internet: www.5point.de | www.teamspace.de | www.projectfacts.de
Vorstand: Thorsten Lenk, Martin Fischer
Aufsichtsratvorsitzender: Prof. Dr. Horst Geschka
Sitz Darmstadt HRB: 76 27


Am 14.06.2012 12:11, schrieb Martin Gruner:

Hi Andreas,

welche Fehlermeldung erhältst du genau?

LG, mg

Am 14.06.12 12:07, schrieb Andreas Laut:

Hallo,
ich habe vor kurzem unser OTRS von Version 2.2.7 auf 3.1.6 
erfolgreich updaten können. Blöderweise sind die Tabellen noch in 
latin1 und nun will ich diese nach utf8 konvertieren.


Das klappt auch wie in der offiziellen Hilfe hier 
 
beschrieben.
Einzige Sache ist - wenn ich den konvertierten Dump einspielen will, 
meckert er über die Tabellendefinition von xml_storage und dass die 
1000 Bytes (für eine MyISAM Tabelle) überschritten wären.
Jetzt habe ich mir die Definition zur xml_storage mal angesehen und 
entdeckt, dass xml_storage.xml_type und xml_storage.xml_key viel zu 
überdimmensioniert sind.


/CREATE TABLE `xml_storage` (
  `xml_type` varchar(200) NOT NULL DEFAULT '',
  `xml_key` varchar(250) NOT NULL DEFAULT '',
  `xml_content_key` varchar(250) NOT NULL DEFAULT '',
  `xml_content_value` mediumtext,
  KEY `xml_type_key` (`xml_type`,`xml_key`),
  KEY `xml_storage_xml_content_key` (`xml_content_key`(100)),
  KEY `xml_storage_key_type` (`xml_key`(10),`xml_type`(10))
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;/
(das ist die momentane Definition)

Kurzum habe ich zur Lösung des Problems die Varchars für xml_type und 
xml_key verkleinert und nun gibts keinen Fehler beim einspielen des 
Dumps.
Was ich mich nun frage, ob ich nicht doch einen Denkfehler habe und 
diese 2 fetten Varchars Sinn machen? Ich will auch nicht 
ausschließen, dass das Problem eine Folge des Update-Marathons ist.


Danke und Gruß
Andreas
--
Andreas Laut | Administration | 5 POINT AG
Tel.: +49 (0) 6151 13097 26 | Fax.: +49 (0) 6151 13097 10
E-Mail:andreas.l...@5point.de

5 POINT AG
Saalbaustraße 27 | 64283 Darmstadt
Tel.: +49 (0) 6151 13097 0 | Fax.: +49 (0) 6151 13097 10
E-Mail:i...@5point.de
Internet:www.5point.de  |www.teamspace.de  |www.projectfacts.de
Vorstand: Thorsten Lenk, Martin Fischer
Aufsichtsratvorsitzender: Prof. Dr. Horst Geschka
Sitz Darmstadt HRB: 76 27


-
OTRS mailing list: otrs-de - Webpage:http://otrs.org/
Archive:http://lists.otrs.org/pipermail/otrs-de
To unsubscribe:http://lists.otrs.org/mailman/listinfo/otrs-de


--
Martin Gruner
Senior Developer R&D

OTRS AG
Europaring 4
94315 Straubing

T: +49 (0)6172 681988 0
F: +49 (0)9421 56818 18
I:www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: 
DE256610065
Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann 
(Vorsitzender), Christopher Kuhn

Verbinden wir uns! OTRS 3.1 schafft einfachere Integration mit Drittapplikationen 
-- Für Frühbucher zum Vorzugspreis:http://www.otrs.com/index.php?id=2361&L=1



-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de
-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

Re: [otrs-de] Statistik über ZIP- oder City-Code?

2012-06-14 Diskussionsfäden Jens Bothe
Hallo,

> Unsere Hotline möchte eine Statistik/Auswertung über einen Parameter machen,
> den ich im Statistik-Modul nicht auswählen kann.


Diese Parameter stehen sicher in der Kundendatenbank und nicht in den
Ticketdaten. Um Daten aus den Kundeninfos in das Ticket zu syncen
benötigst Du ein Add On:
http://www.otrs.com/en/products/otrs-help-desk/features/otrs-feature-add-ons/feature-add-on-storing-ldap-attributes/

Viele Grüße

Jens
-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de


[otrs-de] Statistik über ZIP- oder City-Code?

2012-06-14 Diskussionsfäden Andreas Traub
Hi,



ich stehe derzeit etwas auf dem Schlauch...



Unsere Hotline möchte eine Statistik/Auswertung über einen Parameter machen, 
den ich im Statistik-Modul nicht auswählen kann.

Ist es nicht möglich, eine Auswertung über den ZIP- oder City-Code zu machen?



Kann ich diesen Filter dem Statistik-Modul evtl. hinzufügen?





Grüsse,

Andi
-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

Re: [otrs-de] tabelle xml_storage zu breit mit utf8?

2012-06-14 Diskussionsfäden Martin Gruner
Hi Andreas,

welche Fehlermeldung erhältst du genau?

LG, mg

Am 14.06.12 12:07, schrieb Andreas Laut:
> Hallo,
> ich habe vor kurzem unser OTRS von Version 2.2.7 auf 3.1.6 erfolgreich
> updaten können. Blöderweise sind die Tabellen noch in latin1 und nun
> will ich diese nach utf8 konvertieren.
>
> Das klappt auch wie in der offiziellen Hilfe hier
> 
> beschrieben.
> Einzige Sache ist - wenn ich den konvertierten Dump einspielen will,
> meckert er über die Tabellendefinition von xml_storage und dass die
> 1000 Bytes (für eine MyISAM Tabelle) überschritten wären.
> Jetzt habe ich mir die Definition zur xml_storage mal angesehen und
> entdeckt, dass xml_storage.xml_type und xml_storage.xml_key viel zu
> überdimmensioniert sind.
>
> /CREATE TABLE `xml_storage` (
>   `xml_type` varchar(200) NOT NULL DEFAULT '',
>   `xml_key` varchar(250) NOT NULL DEFAULT '',
>   `xml_content_key` varchar(250) NOT NULL DEFAULT '',
>   `xml_content_value` mediumtext,
>   KEY `xml_type_key` (`xml_type`,`xml_key`),
>   KEY `xml_storage_xml_content_key` (`xml_content_key`(100)),
>   KEY `xml_storage_key_type` (`xml_key`(10),`xml_type`(10))
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
> /*!40101 SET character_set_client = @saved_cs_client */;/
> (das ist die momentane Definition)
>
> Kurzum habe ich zur Lösung des Problems die Varchars für xml_type und
> xml_key verkleinert und nun gibts keinen Fehler beim einspielen des Dumps.
> Was ich mich nun frage, ob ich nicht doch einen Denkfehler habe und
> diese 2 fetten Varchars Sinn machen? Ich will auch nicht ausschließen,
> dass das Problem eine Folge des Update-Marathons ist.
>
> Danke und Gruß
> Andreas
> -- 
> Andreas Laut | Administration | 5 POINT AG 
> Tel.: +49 (0) 6151 13097 26 | Fax.: +49 (0) 6151 13097 10
> E-Mail: andreas.l...@5point.de
>
> 5 POINT AG
> Saalbaustraße 27 | 64283 Darmstadt
> Tel.: +49 (0) 6151 13097 0 | Fax.: +49 (0) 6151 13097 10
> E-Mail: i...@5point.de 
> Internet: www.5point.de | www.teamspace.de | www.projectfacts.de
> Vorstand: Thorsten Lenk, Martin Fischer
> Aufsichtsratvorsitzender: Prof. Dr. Horst Geschka
> Sitz Darmstadt HRB: 76 27 
>
>
> -
> OTRS mailing list: otrs-de - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs-de
> To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

-- 
Martin Gruner
Senior Developer R&D

OTRS AG
Europaring 4
94315 Straubing

T: +49 (0)6172 681988 0
F: +49 (0)9421 56818 18
I:  www.otrs.com/

Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: 
DE256610065
Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann 
(Vorsitzender), Christopher Kuhn

Verbinden wir uns! OTRS 3.1 schafft einfachere Integration mit 
Drittapplikationen -- Für Frühbucher zum Vorzugspreis: 
http://www.otrs.com/index.php?id=2361&L=1



-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

[otrs-de] tabelle xml_storage zu breit mit utf8?

2012-06-14 Diskussionsfäden Andreas Laut

Hallo,
ich habe vor kurzem unser OTRS von Version 2.2.7 auf 3.1.6 erfolgreich 
updaten können. Blöderweise sind die Tabellen noch in latin1 und nun 
will ich diese nach utf8 konvertieren.


Das klappt auch wie in der offiziellen Hilfe hier 
 
beschrieben.
Einzige Sache ist - wenn ich den konvertierten Dump einspielen will, 
meckert er über die Tabellendefinition von xml_storage und dass die 1000 
Bytes (für eine MyISAM Tabelle) überschritten wären.
Jetzt habe ich mir die Definition zur xml_storage mal angesehen und 
entdeckt, dass xml_storage.xml_type und xml_storage.xml_key viel zu 
überdimmensioniert sind.


/CREATE TABLE `xml_storage` (
  `xml_type` varchar(200) NOT NULL DEFAULT '',
  `xml_key` varchar(250) NOT NULL DEFAULT '',
  `xml_content_key` varchar(250) NOT NULL DEFAULT '',
  `xml_content_value` mediumtext,
  KEY `xml_type_key` (`xml_type`,`xml_key`),
  KEY `xml_storage_xml_content_key` (`xml_content_key`(100)),
  KEY `xml_storage_key_type` (`xml_key`(10),`xml_type`(10))
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;/
(das ist die momentane Definition)

Kurzum habe ich zur Lösung des Problems die Varchars für xml_type und 
xml_key verkleinert und nun gibts keinen Fehler beim einspielen des Dumps.
Was ich mich nun frage, ob ich nicht doch einen Denkfehler habe und 
diese 2 fetten Varchars Sinn machen? Ich will auch nicht ausschließen, 
dass das Problem eine Folge des Update-Marathons ist.


Danke und Gruß
Andreas

--
Andreas Laut | Administration | 5 POINT AG
Tel.: +49 (0) 6151 13097 26 | Fax.: +49 (0) 6151 13097 10
E-Mail:andreas.l...@5point.de

5 POINT AG
Saalbaustraße 27 | 64283 Darmstadt
Tel.: +49 (0) 6151 13097 0 | Fax.: +49 (0) 6151 13097 10
E-Mail:i...@5point.de
Internet:www.5point.de  |www.teamspace.de  |www.projectfacts.de
Vorstand: Thorsten Lenk, Martin Fischer
Aufsichtsratvorsitzender: Prof. Dr. Horst Geschka
Sitz Darmstadt HRB: 76 27

-
OTRS mailing list: otrs-de - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs-de
To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de