I was making tests with SubSonic with SQL Server and everything was fine.
I decided to install MySQL and made the same tests, but now I have a little problem
My table name is ClienteEndereco in SQL Server but when i make change in my web.config to work with MYSQL and recompile the program the table name comes Clienteendereco
SQL Server = Cliente**E**ndereco
MySql = Cliente**e**ndereco
I tried to use regexIgnoreCase="true" but nothing happens.
Can anyone help to solve that? How to make subsonic "ignores case" in SQL Server and MySql?
Thank you.
<add name="mssql"
type="SubSonic.SqlDataProvider, SubSonic"
connectionStringName="mssql"
fixPluralClassNames="false"
generatedNamespace="ModeloDados"
regexMatchExpression="A-Za-z"
regexIgnoreCase="true"
removeUnderscores="false"
setPropertyDefaultsFromDatabase="true"
generateNullableProperties="true"
useExtendedProperties="true"
useUtc="true"/>
As Pawel pointed out MySQL on Windows and OS X uses only lowercase names for tables by default. There is a configuration option that you can use to change this behaviour. The following blog posting gives a brief overview:
MySQL Case-sensitivity issues
I founded one way..I used the "regexDictionaryReplace" . This way work in mysql and mssql
<add name="mysql" type="SubSonic.MySqlDataProvider, SubSonic"
regexDictionaryReplace="Empresaendereco,EmpresaEndereco"
fixDatabaseObjectCasing="true" connectionStringName="mysql"
generateRelatedTablesAsProperties="true"
fixPluralClassNames="false"
generatedNamespace="ModeloDados"
regexIgnoreCase="true"
removeUnderscores="false"
setPropertyDefaultsFromDatabase="true"
generateNullableProperties="true"
useExtendedProperties="true"
useUtc="true" />
Thanks for all help!!!
Related
Python 3.8.8 programm with Flask 2.0.1 and Flask-SQLAlchemy 2.5.1
MySql database, collation of the tables: utf8_general_ci.
I'm using two other sqlserver DB with SQLALCHEMY_BINDS. Everything runs on Windows 10.
Some chars from select queries on the MySql DB comes wrong: "situazione è decisamente migliorata"
should be: "situazione è decisamente migliorata"
This would solve the problem:
mystring.encode('cp1252').decode('utf8')
but I need a solution at program level. I tried:
appending to SQLALCHEMY_DATABASE_URI connection string:
"?charset=utf8" or "?charset=cp1215" and others
setting app.config['MYSQL_CHARSET'] and
app.config['MYSQL_DATABASE_CHARSET'] to 'utf8', 'utf8mb4', 'latin1', 'cp1252'
...
passing a parameter to SQLAlchemy like db = SQLAlchemy(use_native_unicode="utf8"), many variations here too
No attemp worked. Please I need suggestions.
Are you looking for a way to specify per database connection encoding ?
For all connections try to use
app.config['SQLALCHEMY_ENGINE_OPTIONS'] = {'encoding': 'cp1252'}
For specific connections to different DBs you can also use engine_options:
engine = create_engine('mysql://user:password#hostname/dbname',
encoding='cp1252')
Got the solution.
The problem was not a problem.
The person who build the original database (that is quite old) coded wrong some characters.
Some of my approaches and the one suggested by olegsv, worked, I checked that debugging deep down into into sqlalchemy data structures, the driver accepted the characters encoding, but the very chars in data were themself worong.
This was unespected.
Maybe I should delete the whole question.
I've made an application in Java EE that uses Hibernate to communicate with MySQL. It works perfectly on my Windows development machine, but I have problem on debian, where the application is deployed.
When I search for keyword with Polish letters(like ł, ą, ć, ó etc,) the result is ok on Windows, but on server, where I have imported the database it does not work.
Hibernate query looks like this:
#NamedQuery(name = "Keyword.findByKeyword", query = "SELECT k FROM Keyword k WHERE k.keyword = :keyword")
and is called like this:
myEntityManager.createNamedQuery("Keyword.findByKeyword").setParameter("keyword", keyword).getSingleResult();
When I use mysql on debian via SSH and type in SELECT query manually:
SELECT * FROM keywords WHERE keyword = 'ser żółty';
it also works and return single result. Encoding and collations of tables and columns are also ok. In datasource configuration I've added
?UseUnicode=true&characterEncoding=utf8
parameters, but it also did not help. I thought that maybe there is a problem with encoding in data from request send by form, but the problem appears even if the parameter i.e. "ser żółty" is hardcoded in my repository class.
I also use Hibernate Search for indexing and the FullTextEntityManager return correct results with Polish letters.
I assume that there is some problem between Hibernate and MySQL, but I have no more ideas what could I change. Any suggestions?
Server Wildfly9.0.1, MySQL 5.6
Ok the problem was in encoding on the mysql server level. It was set to latin1 by default. To fix this follow this question Change MySQL default character set to UTF-8 in my.cnf? and edit your my.cnf file.
I just updated the JDBC driver for my application from
mysql-connector-java-3.1.12-bin.jar
to
mysql-connector-java-5.1.34-bin.jar.
With the v3.x driver, this kind of a query works:
select concat("<a href>", count(sakila.payment.payment_id), "</a>")
from sakila.payment;
But now with the new v5.x driver, the query only works with a cast().
select cast(concat("<a href>", count(sakila.payment.payment_id), "</a>")
as char(30)) from sakila.payment;
Is there any property in the MySQL database I can change?
I don't want to change hundreds of queries like that.
I suspect that you will have to bite the bullet and update your code. There is a bug report here that seems to match your circumstances and the status of that bug report is "Won't fix". The response from the developers ([4 Apr 2007 17:43] Reggie Burnett) was:
This is something that we can't really fix. Let me explain.
MySQL has several issues when it comes to reporting whether a result if binary or not. This was very bad on MySQL versions prior to 5.0 but it's still a problem even today. The SQL you reported is returned by MySQL as binary when it obviously is not. The connector can't know for sure. With 5.0.5 and 5.0.6, we tried to make a "best guess" but that code caused more problems than it solved, so with 5.0.7 we have rolled it out. Your SQL will return string properly with 5.0.7, but that doesn't mean it's fixed. In fact, it returns string because we are ignoring the binary flag so that means you could generate valid SQL that should return binary and 5.0.7 will return string.
Until the server is fixed, the connector just can't always do the right thing. I hope this has cleared it up somewhat.
I'm using Entity Framework with MySQL, and my Linq Query:
db.Persons.Where(x => x.Surname.StartsWith("Zyw")).ToList();
..is producing the SQL:
SELECT PersonId, Forename, Surname
FROM Person
WHERE (LOCATE('Zyw', Surname)) = 1
...and it would seem that this doesn't make use of the index on Surname.
If LOCATE is replaced with the equivalent LIKE, the query speedily returns the required results. As it is it takes all afternoon.
Why is Entity Framework and its connecting drivers opting for this wierd LOCATE function / how can I make it use LIKE instead / why is MySQL making a poor index decision for the LOCATE function / how can I make it better?
Update:
I'm afraid I was guilty of over simplifying my code for this post, the Linq producing the error is in fact:
var target = "Zyw";
db.Persons.Where(x => x.Surname.StartsWith(target)).ToList();
If target term is hard coded, the SQL generated does indeed use LIKE, but with a variable term the SQL changes to use LOCATE.
This is all using the latest generally available MySQL for Windows as delivered by MySQL Installer 5.6.15.
Update:
A couple more notes to go with the bounty; am using:
Visual Studio 2010
EntityFramework 6.0.2
MySQL Installer 5.6.15,
which in turn gives:
MySql.Data 6.7.4
MySql.Data.Entities 6.7.4
The Entity Framework code is generated database first style.
I've also tried it with the latest connector from Nuget (MySql.Data 6.8.3) and the problem is still there.
It's likely your problem is caused by:
You are using an older connector with the bug.
You have a special case (using a variable to hold the .Contains search) described as a bug here
Does your case fall into any of those?
This looks like a regression of MySQL bug #64935 to me.
I can confirm that, using the same builds of EF6 and MySQL Connector, I'm getting the same SQL generated too:
context.stoppoints.Where(sp => sp.derivedName.StartsWith(stopName));
...logs as:
SELECT
`Extent1`.`primaryCode`,
...
`Extent1`.`stop_timezone`
FROM `stoppoints` AS `Extent1`
WHERE (LOCATE(#p__linq__0, `Extent1`.`derivedName`)) = 1
Entity Framework: 6.0.2
MySQL Connector.Net: 6.8.3
I have reported this as a MySQL bug regression.
I have a lot of services which query the database. All of them work fine but one service calling a stored procedure gives me following error:
Could not find server 'dbo' in
sys.servers. Verify that the correct
server name was specified. If
necessary, execute the stored
procedure sp_addlinkedserver to add
the server to sys.servers.
I have not idea why all the other stored procedures work fine and this one not...
By the way, I use SubSonic as data access layer.
Please run select name from sys.servers from the server which you mentioned as default server in configuration file.
Here in name column values should match with your server names used in the report query.
e.g serverXXX.databasename.schema.tablename
serverXXX should be there in the result of select name from sys.servers otherwise it gives error as got.
It sounds like there is an extra "." (or two) in the mapping - i.e. it is trying to find server.database.schema.object. Check your mapping for stray dots / dubious entries.
Also make sure that the server name matches what you think it is. If you rename the host that SQL Server is running on, you need to rename the SQL Server, too.
http://www.techrepublic.com/blog/datacenter/changing-the-name-of-your-sql-server/192
I had another issue with the same exception so I'll post here if someone stumble upon it:
Be careful if you specify the server name in synonyms. I had a different server name on my staging machine and production and it caused the same 'cannot find server'-error.
(Guess you shouldn't use synonyms that much anyway but it's useful in some migration scenarios)
In my case i was facing same issue with following ,
SqlCommand command = new SqlCommand("uspx_GetTemplate", connection);
but after adding square bracket to stored procedure name it get solved.
SqlCommand command = new SqlCommand("[uspx_GetTemplate]", connection);