I need to connect a .net application to a mysql database. When I add the tables to the model, all the columns with the type Tinyint are mapped like boolean.
After Searching in mysql forum, i add "Treat Tiny As Boolean=false" in the connection string. When I refresh the model, nothing changes. If I change the type manually to Sbyte or Int 16 I get the following error.
Error 43 Error 2019: Member Mapping specified is not valid. The type 'Edm.SByte[Nullable=True,DefaultValue=]' of member 'personacion' in type 'Model.perfiles' is not compatible with 'MySql.usmallint[Nullable=True,DefaultValue=]' of member 'personacion' in type 'Model.Store.perfiles'. C:\Proyectos\StatusXMLGenerator\StatusXMLGenerator\StatusXMLGenerator\Model.edmx 474 17 StatusXMLGenerator
Error 42 Error 2019: Member Mapping specified is not valid. The type 'Edm.Int16[Nullable=False,DefaultValue=]' of member 'id_seccion' in type 'Model.formularios' is not compatible with 'MySql.bool[Nullable=False,DefaultValue=]' of member 'id_seccion' in type 'Model.Store.formularios'. C:\Proyectos\StatusXMLGenerator\StatusXMLGenerator\StatusXMLGenerator\Model.edmx 454 17 StatusXMLGenerator
The error 42 has also an incorrect mapping. It says that the type of the column is Mysql.Bool, but in the databases, I have stored values from 1 to 10, so it should be Mysql.usmallint, like in error 43.
This is my connection string:
<add name="ModelContainer" connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=MySql.Data.MySqlClient;provider connection string="server=**********;user id=*******;password=*****;database=pki_2010;persistsecurityinfo=True;Treat Tiny As Boolean=false;"" providerName="System.Data.EntityClient" />
Any ideas?
Solved.
If there is anyone on my situation this is the solution.
1º Add "Treat Tiny As Boolean=false" to the connection string.
2º Build to refresh the new value of the connection string
3º Open the model as XML and set the values of the columns to "tinyint" (The schema should be something like:
<edmx><schema><entitycontainer><entitytype><property name="..." type="tinyint">...
4º Open the model with the designer and map the columns to Sbyte
5º Save and build again.
Related
I'm getting an error from OrmLiteWriteCommandExtensions in my log, and I can't seem to find where this happens. I have no loss of data; when I have the logfactiory set to null, it breaks on no errors; I have set it to allow zero date, but that didn't help. I not sure how to debug this or get around it. It clogs up my logg with statements that I can't track.
This occurs on both linux and windows.
Doesn anyone have an idea how to get at this?
OrmLiteWriteCommandExtensions System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.ParseExact(String s, String format, DateTimeFormatInfo dtfi, DateTimeStyles style)
at System.DateTime.ParseExact(String s, String format, IFormatProvider provider, DateTimeStyles style)
at ServiceStack.Text.Common.DateTimeSerializer.ParseShortestXsdDateTime(String dateTimeStr)
at ServiceStack.OrmLite.Converters.DateTimeConverter.FromDbValue(Type fieldType, Object value)
at ServiceStack.OrmLite.OrmLiteWriteCommandExtensions.PopulateWithSqlReader[T](T objWithProperties, IOrmLiteDialectProvider dialectProvider, IDataReader reader, Tuple`3[] indexCache, Object[] values)
UPDATE:
The logging occurs in the correct file set in the nlog config file, BUT for this exception only it does not conform to formatting in the layout set for NLOG (all other exceptions do!).
Layout string:
${longdate} ${machinename} ${logger} ${level} ${message} ${onexception:EXCEPTION OCCURRED:${exception:format=type,message,method:maxInnerExceptionLevel=5:innerFormat=shortType,message,method}}
UPDATE2 SOLVED:
So this was fun... Before I start to explain how I solved it I have to say that I have no idea why it writes in the correct log file, but ignore all formatting for logging errors - that be another dragon to slay for another time.
So the problem was that a varchar field in the mysql database had birthdate as string and the implicit conversion between DateTime in dotnet to string thre an error.
After changing the field to datetime in thet database the error went away.
Funny thing is that I hade to set minlevel to trace to get the error in context with its call to the database - but it still ignored all error formatting, had no stacktrace, no sql statement, and no line number associated with the error in the log.
So the problem was that a varchar field in the mysql database had birthdate as string and the implicit conversion between DateTime in dotnet to string thre an error.
After changing the field to datetime in thet database the error went away.
Funny thing is that I had to set minlevel to trace to get the error in context with its call to the database - but it still ignored all error formatting, had no stacktrace, no sql statement, and no line number associated with the error in the log.
Searching, reading forums and all suggestion of SO before writing. (1 day already investigating the issue).
Im using: MySql Server 5.5 with Entity Framework 4.3 with Connector 6.5.4
(I was using connector 6.3.6 and everything worked perfectly, updated and problem occurs)
I have a SP that returns an List of an Entity Object. That Entity have a bool (tinyint(1)) field BUT when using the SP it returns it as string.
I created a temporary table and return that but the same problems occurs. The error is:
System.InvalidOperationException: The 'isDeleted' property on 'Container' could not be
set to a 'String' value. You must set this property to a non-null value of type
'Boolean'. at
System.Data.Common.Internal.Materialization.Shaper.ErrorHandlingValueReader`1.
GetValue(DbDataReader reader, Int32 ordinal)
Problem is, since it's a Entity object, i cannot Convert.ToBoolean() [also i dont want to].
I think the problem is that i don't have the ability to cast the SP field as bool or the connector has a bug (most likely).
As I said, it worked with no problem with connector 6.3.6
Thanks.
The bug is there but I found a workaround. The problem happend when the order of the fields aren't the same.
This BUG: http://bugs.mysql.com/bug.php?id=53166 helped me to understand and try making the select order of fileds the same the table.
Example:
If table is :
field_a, field_b, field_c
and your stored procedures returns: field_b, field_a, field_c won't work.
Changed my SP to return field_a, field_b, field_c
I'm using a reflected sqlalchemy mapped class into a SQL Server table.
I DBSession.add() instances of Activities class (the mapped class) with data I get from a different source.
and then I called transaction.commit() (since I'm calling from tg2 I can't use session.commit())
the error traceback:
DataError: (DataError) ('22001', '[22001] [Microsoft][ODBC SQL Server Driver][SQ
L Server]String or binary data would be truncated. (8152) (SQLExecDirectW); [010
00] [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been termin
ated. (3621)') u'INSERT INTO [NOAR_LOADEVENTS] ([EVENTCODE]) VALUES (?)' ((u'210
401',), (u'210402',), (u'210602',), (u'210603',), (u'000010',), (u'000102',), (u
'000206',), (u'000107',) ... displaying 10 of 49 total bound parameter sets ...
(u'211302',), (u'210403',))
be glad to any help about this since I'm clueless how to continue/debug this from here
edit: I had a suspicion that this has something to do with unicode so I changed the sqlalchemy column to unicode.
maybe the DataError is stuck somehow and I need to call a rollback, but I don't know hot to call a rollback in transaction in tg2
edit:the EVENTCODE column in the mssql is:datatype:PK,nvarchar(6), not null
hope this helps
another edit: the insert code (the relevant part)
event = #json with data
ac['EVENTCODE']=event.get('code')#for example u'210602' - from the failing data
...
...
e = Activities(**ac) # this is the class mapped with sqlalchemy to the NOAR_LOADEVENTS in sqlalchemy.
DBSession2.add(e)
transaction.commit()
solved. #beargle comment led me in the right direction. seems the problem strangly enough was trying to insert to nvarchar field with length of 6. seems that a unicode string with a length of 6 like: u'110110' would produce an error while a string '110110' passes fine. so i use
variable.encode('utf-8') and everything work.
what ever.
I jumped into this error and I solved it by changing the definition of a column (DB side) from NVARCHAR(100) to NVARCHAR(200).
I have an oledb connection to mssql and an ado.net destination (with odbc driver used) to mysql. The tables are exectly the same and all the columns are working bar one.
The error message received is:
[ADO NET Destination [325]] Error: An exception has occurred during data insertion, the message returned from the provider is: Unable to cast object of type 'System.DateTime' to type 'System.Char[]'.
I've seen similar questions on other data types but the resolution of changing to string does not work here. If I convert to string (has to be length 29 otherwise the conversion step fails) I get the following error message:
[ADO NET Destination [325]] Error: An exception has occurred during data insertion, the message returned from the provider is: ERROR [HY000] [MySQL][ODBC 5.1 Driver][mysqld-5.5.15]Incorrect datetime value: '2011-03-21 11:23:48.573000000' for column 'LastModificationDate' at row 1
Other potentially relevant details:
connection driver- {MySQL ODBC 5.1 Driver}
script run before dataflow - set sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ANSI_QUOTES'
Other datetime columns are working
This column has a reasonably high proportion of nulls
mssql spec: [LastModificationDate] [datetime] NULL
mysql spec: LastModificationDate datetime NULL
Has anyone had experience with this issue and could provide some advice on resolving it?
Can you try converting it to string on sql server side in your query using:
convert(char(10),LastModificationDate,111)+' '+convert(char(8),LastModificationDate,108)
This works for me all the time.
I got the same big headache this week. I tried many ways. Thanks God, finnally, one of them worked. Hope it could help you a little bit.
For some columns with the data type of Int, datetime, decimal....,here, I identified as ColumnA, and I used it as datetime type.
1.in Data Flow Source, use SQL Command to retrieve data. Sth like select isnull(ColumnA,'1800-01-01') as ColumnA, C1, C2, ... Cn from Table
Make sure to use Isnull function for all columns with the datatype mentioned before.
2.Excute the SSIS pkg. It should work.
3.Go back to Control Flow, under the data flow task, add SQL Task control to replace the data back. I mean, update the ColumnA from '1800-01-01' to null again.
That works for me. In my situation, I cannot use ignore failure option. Because if I do, I will lose thousands rows of data.
I am not able to call setNull on PreparedStatement using MS Access (sun.jdbc.odbc.JdbcOdbcDriver)
preparedStatement.setNull(index, sqltype).
Is there a workaround for this? For LONGBINARY data type, I tried the following calls, neither worked.
setNull(index, java.sql.Types.VARBINARY)
setNull(index, java.sql.Types.BINARY)
java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver]Invalid SQL data type
at sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6957)
at sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7114)
at sun.jdbc.odbc.JdbcOdbc.SQLBindInParameterNull(JdbcOdbc.java:986)
at sun.jdbc.odbc.JdbcOdbcPreparedStatement.setNull(JdbcOdbcPreparedStatement.java:363)
The answer that I have observed to work "quite well" for binding null to most data types with JDBC 4.1, Java 7, MS Access 2013 and the JDBC-ODBC bridge is this one, which I've built into jOOQ:
switch (sqlType) {
case Types.BINARY:
case Types.VARBINARY:
case Types.LONGVARBINARY:
case Types.BLOB:
stmt.setNull(nextIndex(), Types.VARCHAR);
break;
default:
stmt.setString(nextIndex(), null);
break;
}
I just tested this and for an OLE Object (LONGBINARY) field in an Access 2010 database I found that all five of these variations allowed me to specify a null value as the parameter to a PreparedStatement using vanilla JDBC/ODBC Driver={Microsoft Access Driver (*.mdb, *.accdb)}:
s.setNull(4, java.sql.Types.LONGNVARCHAR);
s.setNull(4, java.sql.Types.LONGVARCHAR);
s.setNull(4, java.sql.Types.NCHAR);
s.setNull(4, java.sql.Types.NVARCHAR);
s.setNull(4, java.sql.Types.VARCHAR);
It is particularly interesting that
s.setNull(4, java.sql.Types.LONGVARBINARY);
does not work, considering that when we retrieve an OLE Object from an Access database what we get is a java.sql.Types.LONGVARBINARY according to a ResultSetMetaData object:
String SQL;
SQL = "SELECT Photo FROM City WHERE City_ID = 12";
s = conn.createStatement();
s.executeQuery(SQL);
ResultSet rs = s.getResultSet();
ResultSetMetaData rsmd = rs.getMetaData();
String accessTypeName = rsmd.getColumnTypeName(1);
int javaType = rsmd.getColumnType(1);
String javaTypeName = (
javaType == java.sql.Types.LONGVARBINARY
? "java.sql.Types.LONGVARBINARY"
: "some other Type"
);
System.out.println(String.format("The database-specific type name for this column is '%s'", accessTypeName));
System.out.println(String.format("The SQL type for this column is: %d (%s)", javaType, javaTypeName));
That returns:
The database-specific type name for this column is 'LONGBINARY'
The SQL type for this column is: -4 (java.sql.Types.LONGVARBINARY)
The Wikipedia article on ODBC includes a history suggesting that after an earlier effort ("SQL/CLI") became part of the ISO SQL standard, Microsoft essentially forked their own version and eventually came up with ODBC. If that is the case, then early efforts to conform to an "ODBC 'standard'" may have faced the same difficulties as those trying to conform to Microsoft's RTF document "standard": the "standard" was whatever Microsoft implemented and was subject to change at Microsoft's sole discretion.
However, Microsoft's 1995 ODBC White Paper, available via the download link here, consistently refers to the "OLE Object" datatype as mapping to "*BINARY" or "raw" types (or, in the case of SQL Server, to the now-deprecated IMAGE datatype). So, the CHAR/BINARY discrepancy doesn't appear to be a case of some early ODBC quirk that just got perpetuated.
Certainly this mystery is not new. A forum thread here from ~11 years ago suggests that this issue arose when something changed after JDK 1.4 was released.
And finally, Oracle has stated that the JDBC-ODBC Bridge "will be removed in JDK 8" (ref: here). So, if there hasn't been an "official" explanation (or a fix, for that matter), it is becoming increasingly unlikely that any will be forthcoming.
I saw a similar error once when I was sending a SQL query with 2 conditions in the where clause. One of the conditions needed to be quoted. It was a number in varchar format. The MSSQL server required that the condition be quoted or else I saw the error You got in your question.