I have a SQL Server 2008 database with an Access front-end. My problem is that Access does not recognise SQL Server's dates as they are in a different format.
SQL Server-s format is YYYY-MM-DD
Access' format is DD-MM-YYYY
When the date is displayed in a text-box, it is displayed as a string (without the little calendar icon next to it).
Is there anyway I can configure my Access front-end so that it recognises SQL Server's dates?
Cheers.
If you are storing the dates in SQL server as the data type “Date” or “Date2” try changing them to “DateTime” I had this problem linking data from SQL server 2008R2 to access 97, access did not see it as a date and treated it like text
The Microsoft SQL Server Migration Assistant for Access does move the dates over as a Date format. The problem the user has encountered is with a Driver. Microsoft has a new DLL that must be put on a client workstation (or server in the case of Citrix).
Once that is done, all the dates in MS Access will work properly.
My lastest experience with Access 2010 was exactly the same as Access 2003. It required a DLL.
From there, investigate using a DNS-Less connection string.
I just ran in to this, thanks everyone for your input.
I'm also developing an Access UI for a SQL Server backend (Access 2010/SQL Server 2014) and just encountered this problem. The Date datatype takes 3 bytes of storage, and since I didn't need a time component, that's what I wanted. Personally I'm using SmallDateTime, it takes 4 bytes compared to DateTime's 8. There's also DateTime2 that takes 6-8 bytes.
I created a four field table using each of the date datatypes to experiment with input formats, I think SmallDateTime will do the trick for me.
Related
Maybe somebody can provide assistance for the following question:
I have a SSIS package with Target SQL Server Version 2014. I am not 100% sure which version my target server is running, but it is at least 2014, but i assume its 2016.
I have developed the package with SQL Server Data Tools 2015. It contains of:
Flat File source + Connection Manager
OLEDB Destination
Conversion Step
The source file is encoded in UTF-8, the target database uses ANSI 1252. The file is located on a network drive (essentially the same windows server the SQL Server with the target database is running on).
Contained in the file is a decimal field with precision, scale 18,2. The actual data in the field is always 0.00.
I have specified the input field in the connection manager as decimal.
Now my question: when i execute the package directly in Visual Studio (Data Tools), it works flawlessly, all rows are imported into the target table.
When I call the dtsx package from an SQL Server Agent Job (it is the only step) it fails with a conversion error regarding the decimal field:
Source: Data Flow Task Flat File Source [88] Description: Data conversion failed. The data conversion for column "xxx" returned status value 2 and status text "The value could not be converted because of a potential loss of data.".
The error also arises when i switch between target server versions 2014 / 2016.
A list of things i tried without being successful:
remove column headers from the input file
test it with only one data row... no success.
created a new solution with a new dtsx package and a slightly different input path
deleted the SQL Server agent job and created a new one
changed the encoding of the input file to UTF-8
I didnt find a solution for this exact error phenomenon on the net.
Can anyone provide help?
Many thanks in advance!
Got it. The reason lies in the different decimal formats being awaited when calling the package from the SQL Server Agent Job versus the execution directly in Visual Studio / SQL Server Data Tools.
The Locale Id of the SSIS / dtsx package was by default set to "German" (which is the default language of my OS) whereas the language in effect on the target SQL Server is "English (US)". The input file contains the decimal values in the US format (dotted).
As soon as i changed the locale ID of the package to "English (United States)" it worked. (it would be also possible to change the decimal separator from a dot to a comma in the input file and leave the SSIS locale ID on German).
Obviously the execution via Visual Studio ignores the language setting on the server (otherwise it would crash in that mode too...)
this seems to be a rather similar question (it lead me to the correct solution):
https://dba.stackexchange.com/questions/88895/difference-in-number-format-comma-and-dot-on-ssms-and-ssis
I am developing an Access application on Access 2019. I have split my project into a frontend and backend. I am trying to deploy the application to a user that is using Access 2016. When linking the backend tables in the frontend file, I run into this error:
The Microsoft Access database engine cannot read the data in Receiving.
The minimum required version to read the data is 16.0.7124.1000.
This only happens for two of my tables however, Customer and Receiving. These are the only 2 tables to use an AutoNumber field with the Field Size set to Long Integer.
Is this an issue with the AutoNumber? Or is the Long Integer field size not supported in Access 2016? Wondering what the best option is for me to link this table to a 2016 version from a 2019 version.
Edit:
Here is the output of the Database Documenter tool for the Receiving table:
This specific error is caused by the Large Number data type, or BigInt.
You can read the documentation on that here
Note that support has been added to Access 2016 in later updates, that's why the minimum required version starts with 16 which corresponds to Access 2016, so just updating Access 2016 might solve your issue.
Else, remove all large number fields.
Note that Large Number and a number set to Long Integer are entirely different things, a long integer is 32-bit long and supported by all versions of Access, a Large Number is 64-bit long and only supported since Q2 2017, and has certain issues when working with it in VBA.
Access tends to sneak in the Large Number datatype when importing from Excel. I strongly recommend you avoid it unless you really need it, both for compatibility reasons, and to make using your tables in VBA a lot easier.
The rule tends to be simple:
You can near always go forward. That includes word, excel, or Access.
In other words?
You have to develop with and use the lowest common version of Access. So, say you can work with Access 2010. Then 2013, 2016 and 2019 users will have no problems.
But, going "back in time" or "back in versions"?
That tends to be a problem.
So, if you still going to have some users of 2016? Then that has to be what you use for development. This issue often applies to Excel or word. You use the v-next great version and some new feature (or new format)? Then previous versions can experience trouble.
I'm trying to create a completely new database from an existing MySQL database, bringing over both data and schema, but so far the only way I've been able to do this is to first import the MySQL database into MS Access, and then into SQL Server 2005? Crazy right? Surely, there is a way that doesn't involve a tedious, custom time-consuming programming, right (perhaps using SSIS)?
A few additions to my original description above:
Its a pretty good size database (easily a few gigs).
I'm working in an MS environment (asp.net, C#)
I'm under a tight deadline so I'm looking for an automated process that requires little to no effort in the conversion process.
SSIS would be the preferred way via BIDS (VS 2005)
Thanks for all the great input!
I believe that using the phpMyAdmin tool you can script the MySQL database structure and data into a sql script. Then you simply run those two scripts on your SQL Server 2005 database and it should, in most cases, create the database and fill it with data. It's been a couple years since I had to do it myself, but as I recall that was the process I used to transfer a MySQL database to SQL Server in the past. You will probably have to alter the structure script to change some of the data types to their SQL Server equivalents, but the data should load just fine once you've got the data types all sorted.
I think you can use SQLYog to generate some fairly standard SQL which will dump out and recreate your db, with data. You may have to massage its output for SQL Server's dialect of SQL a bit, though...
The responses I received were certainly helpful, but the solution it would seem is to do a mysqldump and then run that script from SSIS, massaging the output as needed; however, AFAIK it is not possible to use VS 2005 BIDS to create an SSIS package that completely transfers a MySQL database to a SQL Server 2005 database (data and schema) using Windows Vista 64. I said AFAIK, but who knows the interwebs have much to reveal :)
I have my application working fully on my development machine and storing data all okay on a SQL 2008 database, how every when I deploy the application to my server, which is running SQL 2008, and the model is stored in the database the date fields do not accept an English date format.
e.g.
13/08/2009
fails
Sounds like you are running with a different culture on the machine you have deployed to, where that date format (US) is not valid. First place to look is the culture set in the Windows Control panel.
If you can't change the machine settings in ASP.NET you can do this through the Web.config file.
CodeProject has an article describing one way to do this for Windows forms.
We store our date/time information in UTC format on our SQL Server.
When using SQL Reporting Services, we'd like to display this data in the time zone of the client workstation, but it appears that using an expression like;
System.TimeZone.CurrentTimeZone.ToLocalTime(Fields!DateStarted.Value)
... converts into the time zone of the server, not of the client workstation?
Is there any way of performing this conversion locally, or passing the local time zone to the server for conversion?
Thanks in advance
Matt
If your reports are standalone I can't see other option than add timezone report parameter.
But if you using reports inside web application, you can Determine Timezone from Request Variables with JavaScript and send time zone value back in hidden fields, urlparameter or postback.
You can also add timezone to user registration info (or figure it out from Country and City fields).
Also you may try Target Your Visitors Using GeoIP and .NET.