I'm using Npgsql.EntityFramework (2.2.7) to interact with a new PostgreSQL (9.6.2) database installed on windows server 2012. I am experiencing some unexpected behavior while querying the database with parameters of type DateTime. At the time I am supply EF the parameters for the query, they are bound with DateTime.Kind = UTC. However, when I look at the parameters using an IDbCommandInterceptor, the parameter values are actually bound as DateTime.Kind = Unknown. This is currently causing issues for me as I use the interceptor to ensure that any dates that are inserted/updated/queried against the database are of Kind = UTC to ensure consistent date storage. This works fine with an Oracle database using the Oracle-supplied entity framework driver. I read the documentation at http://www.npgsql.org/doc/types/datetime.html and I was led to believe that the value should be unchanged upon binding. Is this a bug that the Datetime.Kind is being changed within the npgsql driver? Or is this expected behavior? If expected, why?
Thanks in advance!
Related
After so many years, I have become part of a project that use SQL server. This time it's 2017. I found a very weird behavior when I create a table.
create table test (sampledate date)
If I run above and check the data type of column sampledate, it shows nvarchar instead of date. This causes an error in my application.
Btw I'm using DBVisualizer to check the data type, I believe this is not because of this tool.
Have a look at this section of the Microsoft documentation. It explains that with down-level clients, the backward compatibility of the date data type is ensured by being converted to String/Varchar. So it may really comes from the DBVisualizer usage.
For your app, check the version of the client you use.
My Spring Boot application requires to store and express all dates and times in UTC, so the POJOs in the application use OffsetDateTime data type and the SQL Server 2016 database use datetimeoffset(7) column type. The JDBC library is ms-sql 6.1.0.0, a JDBC 4.2 compliant driver. Version of JVM is Oracle Java 8.
I am using Spring JDBC and NamedParameterJdbcTemplate to implement the DAO implementation class. No JPA, ORM, etc.
When inserting a record, I use the jdbcTemplate.update(String, Map<String,Object>). This appears to be working, except that values saved in the database are not the same as what I supplied via the Map. For e.g. namedParameters.put("record_datetime", someEntity.getRecordDatetime()); where that object's recordDatetime property holds the value 2018-05-31T13:20:01Z is saved in the database as 2018-05-31T20:20:01.0000000+00:00. I happen to be in a GMT-7 timezone, but the property uses a datatype of OffsetDataTime with no offset, i.e. it is GMT essentially.
I have a bigger issue on hand when trying to retrieve the value from the database. I use jdbcTemplate.queryForObject(String, Map<String,?>, RowMapper<T>) and in the RowMapper, I use resultSet.getObject("record_datetime", OffsetDateTime.class). This results in an exception:
java.sql.SQLFeatureNotSupportedException: This operation is not supported.
I tried using OffsetDateTime.ofInstant(resultSet.getObject("record_datetime", Instant.class), ZoneId.of("UTC")). Same exception as above is thrown.
This has to be a very common requirement, to be able to store values in UTC, and/or with offset values. In other applications, I employed java.util.Date and either java.sql.Date (or java.sql.Timestamp) in the DAO to persist date or date-time values, and that generally worked well. I am somehow finding this much harder to implement.
I have an access form with a fairly complex query displaying raw test values and the resulting test calculations on a large MS Access Form that was created in access 2007. Every once in a while my data entry guys are complaining that upon leaving and returning to their database form they see an error with text "This expression is typed incorrectly or it is too complex to be evaluated. For example, a numeric expression may contain too many complicated elements...". After this error appears every textbox is populated with the "#NAME?" error code.
I am curious if anyone has experience with this. I recently migrated the backend table from another MS Access database to SQL Server. My table has a primary key in SQL Server and also a timestamp column. Lastly, I have tried to reduce the size of the query that produces the calculations displayed on the form. On top of that not working, it previously worked within Access , so I don't see how simply moving the table to SQL server would cause the size of the query to now be too much.
Any help is appreciated, thanks.
This is a late response but I've recently experienced a similar issue and found it to be data type related.
Check if your SQL Server table's primary key data type is "bigint". If it is this may cause problems reading the data in Access. Access 2016 supports large number types but it needs to be set in Options-->Current Database-->Data Type Support Options. Note that setting large number support will prevent your Access app from working in version prior to 2016.
One suggestion, which may actually speed up the forms as well. Is to rewrite the query you are using as your bound data source for the form as a view on the SQL server.
Then link this view to your MS Access front end and use it as the bound object.
Depending on your requirements, Read/Write, and experience in SQL this may be an easy thing to do or a moderately tough thing to do.
Access is pretty greedy with the network connection so any processing you can move server side is fantastic.
I have a MS Access 2010 front end / SQL Server 2012 back end database, with a number of date fields in different tables. Sometimes I need to store the time, so I have used data types datetime or smalldatetime. However certain fields only need to store the date, so I used data type Date.
My problem is that in MS Access, my ODBC-linked table shows the Date data type fields as Text. This is then leading to problems with some dates being stored in the yyyy-dd-mm format and others in the yyyy-mm-dd format.
Is this a bug? Do I need to use smalldatetime?
Thanks for any assistance,
Jim
Had the same issue myself linking Access 2007 and SQL Server 2008.
See this question, if you look at Albert D. Kallal's comment to the first answer, it tells us that the problem is with an outdated driver connecting the front end to the back end.
If you aren't able to choose an up-to-date driver (and bear in mind that even if you can, other users of your database on different client machines may not be able to) the workaround is to use datetime data type in every case.
Just to expound on the comment given by #BiigJiim I actually had the Native client 11.0 driver already installed but as I was creating DSN-Less table connections I had to change my connection string formally to: Driver={SQL Server Native Client 11.0};
Also as an additional note, I do not believe the Date and DateTime2 data types are recommended for Microsoft Access integration. If memory serves me correctly it recommends either DateTime and SmallDateTime. I get not needing the Time in a lot of circumstances, but you can easily format it via the front end... especially within Access.
I'm currently porting a Access 2003 app to use a SQL Server 2005 back-end, and I'm having trouble with the datetime representations.
As I understand it, the default Access behavior is to use the datetime format defined on the local machine's regional settings, as do SQL-Server. Is there a way to force Access to use another default format (other than those available in the "Format" property dropdown list), something like Format = "dd/mm/yyyy"?
My problem is that a good many forms in the app have sub-forms whose data is linked to the parent via relation implying datetime and numeric values (terrible design, I know.)
Now, when retrieving the data, the date will print ok, using a yyyy/mm/dd hh:mm:ss format, but I cannot make new entries, or inserts from the forms as SQL server will complain that the text-data overflowed the capacity for a datetime, or that the engine cannot find the parent record.
I'm using a file-based DSN to connect to the backend.
Thanks for any insight in the matter,
Pascal
Dates are stored in MS Access as numbers. You can set custom formats for controls, such as dd/mm/yyyy, but it nearly always means a deeper problem.
More info: http://office.microsoft.com/en-ie/access-help/format-property-date-time-data-type-HA001232739.aspx