Forum Replies Created
-
AuthorPosts
-
peterlaursen
Participanthmmm ..
let us try something different. Does the MySQL user that you use for the job have all required privileges, such as 'CREATE' ?
peterlaursen
ParticipantActually I was thinking the same! Possibly an issue with the ODBC driver.
Do you have another program of some kind that can use the ODBC driver? (OpenOffice can but it is a huge download!)
Maybe you can try to import the .mdb into Access itself using ODBC and the DSN?
By the way: when you open the SQLyog Migration Wizard, does it then show the single table in the database?
peterlaursen
Participantyour data displayed in SQLyog after import.
peterlaursen
ParticipantOK .. you replied while I was writing!
try copying the file to another location – your own 'documents' folder for instance if it is not allready.
Your Windws version?
peterlaursen
ParticipantI think that SJA cannot access the .mdb file and that is why SJA will have to abort the job.
An access database is a 'flat file database' – no 'server proces' need to be running to read the data.
However we can import too when the database is open is access, but that may depend on the security settings in access itself and what you are doing.
So please start ensuring that no other program accesses the database file while importing. Also verify that there is no security setting in the database file/folder preventing the actual user to access it (in case 'simple file sharing' is turned off).
peterlaursen
ParticipantIs the database open in Access when you are trying to import?
It imports OK for us!
June 6, 2007 at 9:00 pm in reply to: Sqlyog 6.02rc (not This One Filling Out The Fields Default) #24145peterlaursen
Participantcould you explain again, please? I do not understand you very well!
Basically it is not SQLyog, but the MySQL server that fills DEFAULTs into the rows of a table if a value is not specified in an INSERT statement. But if SQLyog inserts NULL or '' (empty string) or 0 (zero) explicitly then of course any other default will not be inserted. also if a default is specified in the table SCHEMA than SQLyog will/should display that value for every new row! I tested it briefly here and it works for me.
Again I must ask for a test case! (a table schema and a description of what you are doing). When you catch that issue then copy the SQL statement sent by SQLyog form the HISTORY tab!
Still MySQL 4.0.20 ? (in 5.0.x the server behaviour with DEFAULTS will vary with different 'sql-modes')
peterlaursen
ParticipantYou cannot import excel files directly. But there are two ways to import CSV files.
1) Create a table with a structure 'matching' the data in the file. Now you can 'import' from teh table menu or context Wthis you can import and all sorts of text files with data whetehr comma delimited, semicolon delimited or TAB delimited.
2) use the Migration Tool. Define a DSN with the Microsoft text ODBC driver pointing to a specific folder. Every supported file (type) in that folder will be considered a table by the driver. If you have problems with that please detail the problems!
related FAQ's:
peterlaursen
Participantplease clarify: Are you telling that you still (6.02 RC) experience the same problem with LONGTEXT data?
peterlaursen
Participantbug is confirmed and fixed and we wil release version 6.02 RC in a few minutes. Please confirm the fix!
peterlaursen
ParticipantAt our Office we were able to reproduce missimg charcater just like you reported using an US-English Windows XP.
Fixing this is high priority!
peterlaursen
ParticipantMySQL 4.0.26 and SQLyog 5.32 display correct in both DATA and RESULT tab ('default' chosen in connection manager).
so something seems to be broken in RESULT tab when retrieving data from servers where SET NAMES dosn't apply!
peterlaursen
ParticipantAlso the 'mysql' client cannot display those data correctly on my system (probably because my Windows is anotehr language9
From the cmd line dialogue (and it really displays like that in cmd line!):
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 6 to server version: 4.0.26-debug-log
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> use uniaosoc
Database changed
mysql> SELECT * FROM tblimovel WHERE UPPER(endereco) LIKE UPPER('sao sebastiao%'
);
+
+
+
+
+
+
+
+
+–
+
+
+
+
+
+
+| iseq | tipo | bairro | conta | lograd | endereco | numero | complem | d
escricao
| aluguel | vago | iptu | condom | rateio | foto |
+
+
+
+
+
+
+
+
+–
+
+
+
+
+
+
+| 3 | 2 | 9 | 62 | Rua | SÒo SebastiÒo | 698 | apto 400 | T
rÛs dormit¾rios com armßrios sendo uma suÝte com box e gabinete, banheiro social
com box e gabinete, lavabo, sala dois ambientes, cozinha com gabinete e armßrio
s, dependÛncia para empregada, ßrea de serviþo e garagem para um veÝculo.
| 600.00 | N | S | S | NULL | NULL |
| 106 | 4 | 9 | NULL | Rua | SÒo SebastiÒo | NULL | NULL | S
ala com divis¾ria e banheiro coletivo.
| 100.00 | S | S | S | NULL | NULL |
| 107 | 4 | 9 | NULL | Rua | SÒo SebastiÒo | NULL | NULL | S
ala com metragem: 3,00 x 9,00mâ–“ e banheiro privativo.
| 250.00 | S | S | S | NULL | NULL |
| 112 | 4 | 9 | NULL | Rua | SÒo SebastiÒo | NULL | sala 23 | S
ala com metragem 5,50 x 4,00mâ–“ com uma divis¾ria para recepþÒo.
| 130.00 | S | S | S | NULL | NULL |
| 119 | 4 | 9 | 75 | Rua | SÒo SebastiÒo | 818 | sala 01-A | Q
uatro salas medindo 4,00 x 4,00mâ–“ sendo duas com ar condicionado e uma com banhe
iro privativo com box e gabinete, uma cozinha com gabinete e dois banheiros.
| 400.00 | N | S | NULL | S | NULL |
| 180 | 3 | 9 | NULL | Rua | SÒo SebastiÒo | NULL | NULL | D
uas portas de aþo, quatro salas na parte superior com sacada, sala na parte infe
rior, banheiro, cozinha e metragem de 5,00 x 9,00mâ–“.
| 0.00 | N | S | NULL | NULL | NULL |
| 183 | 3 | 9 | 448 | Rua | SÒo SebastiÒo | 506 | sala 10 | S
ala com metragem de 26,00mâ–“ e banheiro privativo.
| 250.00 | S | S | S | NULL | S |
| 192 | 3 | 9 | 857 | Rua | SÒo SebastiÒo | 1447 | NULL | U
ma porta de aþo, banheiro, cozinha, quinta pequeno e metragem de 4,00 x 6,00mâ–“.
| 330.00 | N | S | NULL | NULL | NULL |
| 519 | 2 | 9 | 62 | Rua | SÒo SebastiÒo | 919 | apto 71 | T
rÛs dormit¾rios com armßrios um suÝte com box e gabinete sendo um deles reversÝv
el, banheiro social com box e gabinete, sala ampla, sacada, hall com armßrio, co
zinha com armßrio e gabinete, banheiro de serviþo, ßrea de serviþo e vaga para u
m veÝculo. | 650.00 | N | S | S | NULL | S |
+
+
+
+
+
+
+
+
+–
+
+
+
+
+
+
+9 rows in set (0.01 sec)
peterlaursen
Participantfirst image is MySQL 5.0.41 and second image is 4.0.26.
BTW: I would like to know the language of your Windows too!?
peterlaursen
ParticipantAs your server is 4.0 is is another problem. we do not 'SET NAMES' with 4.0
Still I would like if you executed ” SHOW VARIABLES LIKE '%character%'; “
I tried to import your dump to a 4.0 and 5.0 server. In 5.0 both DATA tab and RESULT tab display Ok, in 4.0 some of the special characters become squares in RESULT – in DATA tab it is OK. So my system recognizes the existence of a character, but cannot display it (but in RESULT only – it displays in DATA!)
Default charset for both servers is 'latin1' and both imports where created with that (no charset spec in the dump file).
Danish Windows Vista.
Please also explain the query “SELECT * FROM tblimovel WHERE UPPER(endereco) LIKE UPPER('sao sebastiao%')”
why the UPPER() function? and why LIKE UPPER('sao sebastiao%') and not LIKE UPPER('sao sebastião%')?
-
AuthorPosts