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
Related
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 am writing a clickonce application in vb.net. I have sql tables linked to a Microsoft Access database, and then my application reads through the OLEDB connection.
My columns in SQL are saved as date however when linked to MS Access they convert to "text" I haven't had any issues with this until I started creating charts on my application. I need the dates on the chart to display as jan 17 feb 17 etc however no matter what formatting I use they come back as '2017-01-01' '2017-02-01'
I have tried
ChartFCR.Series(0).XValueType = DataVisualization.Charting.ChartValueType.DateTime
ChartFCR.ChartAreas(0).AxisX.LabelStyle.Format = "MMMyy"
in various forms and nothing is changing the appearance. any information or suggestion is helpful.
Thanks
The only way Access will make sense of a SQL date data type is if it is converted into 1) a datetime in SQL or 2) a date in Access.
Of course it depends on your situation, but try creating a query in Access that handles that conversion and base the chart on the query. That would give you the most control for the Access interface.
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 am in the UK. I have a Windows 2008 server in Germany with SQL Server 2008 R2 Express installed on it. The regional settings for Windows are set to UK. SQL Server language is set to English. When I run
sp_helplanguage ##LANGUAGE
it shows that it is set to
us_english
I have numerous tables in the database that have float datatypes in them. When I use SSMS to change one of the float values, if I type in
1234.1234
firstly it displays as
1234,1234
then when I click off the row to save it, it displays as
12341234
The ASP.NET application, that is being served the data via a stored procedure and being put into a double (VB.NET), does a
String.Format("{0:#0.0000}", dMyDouble)
This renders as
12341234,0000
Needless to say, on my local server (all UK based) all database entered numbers display as I would expect (1234.1234) and .NET formats them as I would expect (1234.1234). I am aware that my European friends use a different notation to us in the UK, but I need the UK format to be output - and more importantly the float in the database!
The fact that .NET is not formatting correctly, I imagine is purely to do with the fact that the number is not storing the accuracy.
I have also played around a bit by using a decimal column (18, 4) and I get a similar outcome. As I type 1234.1234 using the point (.) it replaces with a comma (,). When the row is saved, it saves as
12341234.0000
You must set the LANGUAGE on your session to the desired setting.
But, despite the fact that you did not show any C# code, the fact that you're seeing formatting issues it means you're passing the values as text in SQL Commands. You should be using #variables instead. This would have the side benefit of avoiding SQL injection issues.
I have a problem I am trying to resolve. We have a SQL Server 2005 running a commercial ERP system. The implication for this is that we cannot change the database structure and all of the character fields are CHAR or VARCHAR rather than Unicode types (NCHAR, NVARCHAR).
We also have multiple instances of the ERP software, based on country. Each country has it's own database on the same database server, which results in variations in the table names based on the instance of the ERP software that is running. For example, the US customer table is called US_CUSTOMER and the UK one is GB_CUSTOMER. We have created a separate database that essentially mirrors the ERP system tables with synonyms, and then views that handle all of our SQL transactions against these synonyms. This was done to use LINQ TO SQL. Thanks for reading this far :)
The issue we have is we are now implementing Simplified Chinese for the application. In the customer ERP system, they set the code page for the ERP system so that when the ERP system writes to the base tables, the data is written as multi-byte. My question is how can I get this multi-byte information translated back to Simplified chinese? I would like to be able to do this at the database level, since I have both a web application and SSRS reports that need to take advantage of it.
Any ideas or directions? I don't think I can change the codepage, since multiple countries are using the same database server (though different databases).
Thanks ahead of time
Are we saying that 2 varchar characters are being using to store 1 unicode character?
If so, try CAST to binary to nvarchar etc (or something similar)
Otherwise, look at COLLATE clauses to coerce data?
Edit:
A CLR function might be your only bet to use Remus' suggestion of MultiByteToWideChar
What we ended up doing for this is writing a CLR function that can be called from our SQL statement. We pass in the string and the desired code page and get a converted string returned. The performance is not what we hoped for, but it seemed to be the only path we could find.