MySQL5.6 unter Windows SBS2011: Datenbank Crash- was nun?

so die Screenshots und meine My.ini kommen hier:
Code:
# Other default tuning values
# MySQL Server Instance Configuration File

[client]
no-beep

# pipe
socket=0.0
port=3306

[mysql]

default-character-set=utf8


# SERVER SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by the MySQL Server. Make sure that
# you have installed the server correctly (see above) so it reads this
# file.
#
# server_type=2
[mysqld]

# The next three options are mutually exclusive to SERVER_PORT below.
# skip-networking

enable-named-pipe

shared-memory

shared-memory-base-name=MYSQL

# The Pipe the MySQL Server will use
socket=MYSQL

# The TCP/IP Port the MySQL Server will listen on
port=3306


# Path to the database root
datadir=C:/ProgramData/MySQL/MySQL Server 5.6/Data

# created and no character set is defined
character-set-server=utf8

# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB

# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

# General and Slow logging.
log-output=FILE
general-log=0
general_log_file="AIRSERVER.log"
slow-query-log=1
slow_query_log_file="AIRSERVER-slow.log"
long_query_time=10

# Binary Logging.
# log-bin

# Error Logging.
log-error="mysql.err"

# Server Id.
server-id=1

# Secure File Priv.
secure-file-priv="C:/ProgramData/MySQL/MySQL Server 5.6/Uploads"

max_connections=151

query_cache_size=1M

table_open_cache=2000

tmp_table_size=129M

thread_cache_size=10

myisam_max_sort_file_size=100G

myisam_sort_buffer_size=248M

key_buffer_size=8M

read_buffer_size=64K
read_rnd_buffer_size=256K

innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=9M
innodb_buffer_pool_size=831M
innodb_log_file_size=48M
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
query_cache_type=1
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000
bind-address = *
Screenshots über die ODBC- DSN und die getestete UDL hängen hier an. Und schließlich die Fehlermeldung. Es wäre nett, wenn das jemand nachvollziehen kann und noch eine Fehlerquelle entdeckt.

Gruß Eismann
 

Anhänge

  • odbc.jpg
    odbc.jpg
    52,6 KB · Aufrufe: 1
  • udl.jpg
    udl.jpg
    44,4 KB · Aufrufe: 1
  • migrationError.jpg
    migrationError.jpg
    14,2 KB · Aufrufe: 3
Werbung:
das hat IMHO nix mit der my.ini zu tun sondern daran, daß dem in der Feglermeldung genannten User schlicht Rechte fehlen. Aber ich nix mysql ...
 
ich hab vergessen zu sagen, das diese DB Personendaten speichert. wahrscheinlich waren Daten in dem Dump entweder verschlüsselt oder sonst irgendwie geschützt. Ich sollte mit als den Sql-Inhalt mal genauer ansehen.
können in einem Dump, der eine komplette Datenbank wieder aufbaut, auch Schutzmechanismen enthalten sein? Zur UDL-Datei gehört eine Datei mit einem Schlüssel, die das Migrationtool immer mit einliest.
Und wahrscheinlich kommt es daruf an, dass de künftiger Besitzer=odbc-user dise Datenbank zurückspielt. egal oder wichtig?
 
Werbung:
wir haben uns mittlerweile darauf geeinigt, dass der DB-Server nicht weiter verwendet wird. Die Programme laufen wieder wie früher mit Access und in einigen Monaten geben wir die Systempflege ohnehin an einen externen Anbieter ab. Schade, dass manche Dinge nach 4 Jahren so kläglich beendet werden.
Als Berufskolleg verdient man mit DB's kein Geld und daher ist das ganze dann doch eine Nummer zu groß. Da ich nur alle paar Monate etwas mit der DB zu tun hatte, sollte ich froh sein, dass sie über 4 Jahre so glatt funktionierte. Jetzt machen wir dass, was wir noch alle aus dem ff beherschen: ein paar mdb-Dateien hin und herkopieren.

Ich melde mich, wenn es noch mal in einem anderem DB-Projekt brennt. Oder wenn ich hier mal eine SQL-Abfrage lösen kann.

Lieben Gruß aus Köln
Eismann
 
Zurück
Oben