I've had an odd behaviour last week with a if condition and I would thank any one who has any idea of what had happened. Although I've found a workarroud I don't like to be in the shadows.
Let me explain.
Scenario 0 (this was working before everything exploded)
Langauge: Visual Basic
Net Fwk: 3.5
Client: XP (x86) machine (Winforms)
Database: Access on a Shared Folder of a Win Server 2008 (don't know if x86 or x64)
DB Provider: Jet OleBD
Office: 2007 x86
Why Access?
Low cost, MS Access available for the user and it fits all I needed.
And one day Win7 appeared:
Scenario 1 (here is when everything stopped working)
Langauge: Visual Basic
Net Fwk: 3.5
Client: Win 7 (x64) machine (Winforms)
Database: Access on a Shared Folder of a Win Server 2008 (don't know if x86 or x64)
DB Provider: ACE OleBD x86
Office: 2010 x86
In this new scenario, the application started to work wrong.
And the odissey begins.
First I tested the application on my development machine. The scenario was similar to Scenario 0 so everithing worked ok.
Then I started a Win7 test machine and tried to find if I could get where the problem was:
Scenario 2
Langauge: Visual Basic
Net Fwk: 3.5
Client: Win 7 (x64) machine (Winforms)
Database: Access on a Local Folder
DB Provider: ACE OleBD x86
Office: 2010 x86
I Test the application and everything works fine.
After crying like a baby for 2 or 3 minutes, I decided to connect to my customer's server through internet using my Win7 test machine.
Scenario 3
Langauge: Visual Basic
Net Fwk: 3.5
Client: Win 7 (x64) machine (Winforms)
Database: Access on a Shared Folder of a Win Server 2008 (don't know if x86 or x64)
DB Provider: ACE OleBD x86
Office: 2010 x86
Amazed the same application I run against my local DB, fails against the remote db (just changed the connection string in the config file).
I've started adding debug statement to the application and tested one and again so I could find why it doesn't work as spected.
Finally, I found that the statement
If FinalDate.Subtract(StartingDate).TotalDays + 1 = 7 Then
returns always False in Scenario 1 and 3 (ALWAYS!). And True or False in Scenario 0 and 2.
I've damned Thor and tested this change to the statement
Dim totalDays As Integer = CInt(FinalDate.Subtract(StartingDate).TotalDays)
If totalDays + 1 = 7 Then
As you imagine, this works fine.
But the question is "Why?".
WHY????!!!!
Any idea?
TotalDays:
Gets the value of the current TimeSpan structure expressed in whole
and fractional days.
So if you only need whole-days then it is safest to cast to Integer anyway, and avoid any possible concerns about the time-part.
Related
I have an app that's been working fine in 32 bit using the connection string:
Driver={Microsoft Access Driver (*.mdb)}; Dbq=MyDatabase.mdb;
using ADO in C++ on a PC with no Office installation.
I have converted it to x64 and I believe I need to install some form of Access drivers no matter if the host PC has x64 Office installed or not. So I grab Microsoft Access Database Engine 2016 Redistributable and install it.
In general everything works OK but certain SQL queries are failing. Most noticeably ones that use LIKE '%somevalue%' - now I understand that % is ANSI-92 but it's been working fine as I say so assume that's ADO related (I could change this to ALIKE I guess).
What I don't understand is if I install the Access Database Engine 2010 then all works as expected. It seems that something is different in the Access Database Engine 2016. I did look for some release notes/breaking changes but couldn't find anything.
So my question is are there changes in the way SQL is parsed in Microsoft Access Database Engine 2016 and should I simply get customers to install the 2010 version?
Note: the other query that seems to be failing is a table with a Yes/No field. I have a query that checks: field <> 0 and this throws an exception.
Update: If I install the Microsoft Access 2016 Runtime then all seems to work. So the issue seems specific the Microsoft Access Database Engine 2016
So in summary:
No Office Installed: Installed Access 2016 x64 Database Engine: Query FAILS
No Office Installed: Installed Access 2010 x64 Database Engine: Query PASSES
32bit Office Installed: Installed Access 2016 x64 Database Engine: Query FAILS
32bit Office Installed: Installed Access 2010 x64 Database Engine: Query PASSES
x64 Office Installed: Installed Access 2016 x64 Database Engine: Query PASSES
Where the Query is:
SELECT * from sometable WHERE somefield LIKE '%ABC%';
The setup is:
Window 10 Version 1909
32 bit Office: Microsoft Office MSO 16.0.12325.20280 32bit
64 bit Office: Microsoft Office MSO 16.0.12325.20280 64bit
Access database engine (x64) from here: microsoft.com/en-us/download/details.aspx?id=54920
My app is x64
Are you using SQL Server as the backend database, or Access?
In SQL Server % is the wildcard symbol.
With a pure Access environment, the wildcard standard is usually *
There may be a setting to change this, but I can't recall.
reference: https://support.office.com/en-us/article/like-operator-b2f7ef03-9085-4ffb-9829-eef18358e931
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
Environment: Win8 64 bit, Office 2010 32 bit. Using tips seen here, I installed AccessDatabaseEngine_x64.exe as passive (so that it could be installed with 32 bit Office), and had no connection problems with Access .mdb files until two days ago. Now the connection fails on all .mdb files, with C# debugger showing "unknown error" with "external component". Connection string uses ACE 12.0. I changed nothing in code, which was compiled for 64bit.
I'm building an SSIS package on Microsoft Visual Studio Ultimate 2012 Trial Version to import an access database, but I can't see the correct provider (Microsoft Office 12.0 Access Database Engine OLE DB Provider) from the drop down when creating the connection string. I downloaded the AccessDatabaseEngine_x64 since the installed MS Office is a 64bit, I still can't see this provider that I'm looking for. I'm building this SSIS package on a Windows Server 2012 64 bit machine.
I need to know what I should do to be able to see this provider.
Can somebody help.
OK. this is mostly assumption but holds true for database drivers. I will quickly be downvoted if this is incorrect.
I assume your version of Microsoft Visual Studio Ultimate 2012 is a 32 bit app, so you cannot see 64 bit drivers.
Regardless of what type of install of Office you have, it will create an output file, and that file does not have 'bitness' - i.e. the same file is produced regardless of whether your office app is 32 bit or 64 bit.
You just need to match your SSIS runtime with your driver. So if your SSIS package will be running in 64 bit, you need a 64 bit driver to access an Office file.
If it will be running in 32 bit you need a 32 bit driver.
Normally you just install both versions, develop in 32 bit and run in 64 or 32 bit.
I've got a client that I wrote an asp front end application 2 yrs ago, which connects to a access 2007 database. All the files sat on a windows server 2000 machine 2 yrs ago. They recently upgraded their server to a windows server 2008 machine (64bit). Now the asp can't connect to the Access database via the ODBC connection. I tried using a dsnless connection, as well as, a manually created dsn connection (the manual dsn was created on the server 2008 machine using the 32bit .exe wizard to create dsn connections)...but that didn't work. I get an error that basically says the database odbc couldn't connect.
I've read that this is a problem between a 64bit 2008 server and a 32bit application (access 2007), but I can't seem to find any solutions to fix this problem.
Can anyone point me in the right direction, or offer some help? I'm really clueless how to solve this for them and they really don't have any other people to help.
Thanks for your help.
On a Windows 2008 x64 the following can be done to enable 32 bit applications in IIS:
Open IIS (inetmgr command)
Locate the application pool that your application is using
In the pool's advanced settings, set Enable 32-bit Applications to true
If that doesn't work, try enabling 32 bit compatibility mode by using the following command:
cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 True
Hope it helps!