Actually I am using the next code to compact Access 2003 databases (mdb files). in the past, I've used JRO.JetEngine (but is obsolete).
code:
Add Reference: Microsoft Office 12.0 Access Database Engine Object Library
Dim AccessEngine As New Microsoft.Office.Interop.Access.Dao.DBEngine
AccessEngine.CompactDatabase(File_Path, compact_file, Nothing, Nothing, ";pwd=mypass")
it seems runs fine: no exceptions, no errors, no advices, is created db compacted....But still, I'm not 100% sure because (googling) I have read on other sites that for access 2003 must be used JRO.JetEngine
my above code is correct to compact mdb files (access 2003)? is missing something?
I just tested your code in VB.NET 2010 and it seems to be working fine. It really did compact the Access 2003 database and the compacted database opened okay afterward. So, no, I don't think you're "missing something".
Related
I have been working on an API to run queries on a FoxPro database via PHP (v7.3) using ADODB (v5.20.14). Currently, my working solution uses XAMPP (3.2.2 x86), running on a Windows 2019 server. FoxPro driver (6.01.8629.01).
I'm now trying to get this same setup working using IIS 10, however, I'm running into a strange issue where if I send simultaneous requests to the web server, only the last request will return back data successfully; the issue lies in $db->connect. This is the connect code that I am using:
require_once('adodb/adodb.inc.php');
$db = NewADOConnection("vfp");
$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
$db->debug = true;
$db->connect("DSN=Visual FoxPro Database;UID=;SourceDB=<UNC PATH>.DBC;SourceType=DBC;Exclusive=No;BackgroundFetch=Yes;Collate=Machine;Null=Yes;Deleted=Yes;") or die("Failed to connect.");
The error that I get back on all but the last request is:
odbc_connect(): SQL error: [Microsoft][ODBC Visual FoxPro Driver]This file is incompatible with the current version of Visual FoxPro. Run 30UPDATE.PRG to update the file to the current version., SQL state S1000 in SQLConnect
I have found this KB article on the error which seems to suggest that it's an erroneous error; it's misleading.
If you open a database located on a server numerous times from multiple Visual
FoxPro 6.0 executables, then the following error randomly appears:
This file is incompatible with the current version of Visual FoxPro. Run
30UPDATE.PRG to update the file to the current version.
This error may also occur if you are opening a Visual FoxPro 6.0 database using
ADO or the Visual FoxPro ODBC driver.
I don't believe that this is very helpful as it works when executed via XAMPP, just not IIS. IIS application pools are set to use x86 as ADODB and the FoxPro driver require 32 bit.
I'm not sure what is causing this behavior and why the last request works every time, the connection to the dB is established and data is returned successfully.
Unfortunately, this seems to be an issue with version 6.x of the VFP driver which won't be fixed as VFP was made end of life some years ago; extended support for v9 ended in 2015, you can see the lifecycle here.
I can't speak for the difference between IIS and XAMPP but they use different underlying technologies.
Considering the age of VFP, I presume that you're using v6 to support a legacy system? In which case, there's no fix for this issue other than to use a third party xBase driver which supports VFP, there are plenty out there and should work for your existing setup.
You are saying ADODB but erroneously using ODBC driver, which latest version was 6.x. You cannot access newer version of VFP tables with that driver. Use VFPOLEDB driver instead, it works wonderfully well with ADODB (32 bits). Unfortunately I am not using PHP, so I can't give an example with PHP.
All.
I have used a DLL approach explained on How to securely store Connection String details in VBA
This code is running very well on windows 10 64 bit and MS Office 64 bit. But same copy of the files i am not able to use on Wndows 8.1 Pro and MS Office 64 bit.
DLL generated is converted to host machnines environment by using
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm c:\windows\syswow64\OraConnection.dll /tlb /codebase
But still same error i am facing. About environment variables care has been taken.
My Connection string is
"Provider=OraOLEDB.Oracle; Data Source = ; User ID =; Password=";
In the Succesfull machine i was using Release 12.2.0.1.0 for ODAC 12.2c Release 1 as oracle client.
But saw a latest version of the oracle client as 64-bit ODAC 12.2c Release 1 (12.2.0.1.0) for Windows x64 which was released on 1st June 2017.
Installed the same. And my error was resolved. When i observed system environment variables i saw few things added into it.
E:\app\client\Admin\product\12.2.0\client_1;E:\app\client\Admin\product\12.2.0\client_1\bin;C:\Users\Admin\Oracle\;
I dont know actually what they did. But error was resolved.
Can anybody throw highlight on this?
I'm not sure what the DLL buys you beyond simple obfuscation. All you're doing is making it a bit harder to get to but not actually protecting the privacy of it in any meaningful sense. My normal advice for management of connection strings is to simply don't save user/password. Instead, require the users to input the username/password at runtime and ensure that you have Persist Security Info=false in your OLEDB connection. That way, once it's opened, the full connection string is now inaccessible and there's no reference to a password. That's much more secure than sticking it in a variable in a DLL and crossing your fingers nobody knows how to read a memory dump or attach a debugger.
That said, that's not germane to your question, not able to the use the provider. First thing I'd do is to rule out whether the DLL is causing a problem that you didn't expect by removing it and using the provider directly. If it likewise fails, then you know the DLL has nothing to do with it and you need to work out with Oracle's provider documentation to get to the bottom of the issue.
This is something that start to happen on a project on which I am working, and so far I was not able to figure out the root cause.
This stopped working without any change from my side, the only thing I know has changed since the last time I worked on that project is that a disk failed (used to be the E: drive on which some applications were installed).
Operative System is Windows Server 2003.
Below the error:
Runtime Error
The Libraries I am adding to the project are the following:
Visual Basic For Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft CDO for Windows 2000 Library
Microsoft Scripting Runtime
Windows Scripting Host Object Model
Microsoft Data Binding Collection VB6 (SP4)
Microsoft ActiveX Data Objecrs 2.8 Library
The object oConn is declared and instantiated the following way:
Dim oConn AS ADODB.Connection
Set oConn = New ADODB.Connection
No reference is marked as MISSING in the VB Project.
I also tried the late binding, but without success. I tried to use regsrv32.exe to reregister msado15.dll, but no joy.
I am really out of idea here, I think that some dependencies are no longer satisfied due to the failure of the disk, but I don't know how to investigate this given the few details provided by the IDE.
Thanks
This question has no easy answer. What I found, and has been also suggested in the comment by #Jim Hewitt, is that MDAC on Windows Server 2003 was corrupted. The component checker is not actually able to identify the version of MDAC, which is an embedded component in that version of Windows.
So, summarizing, the whole windows installation is corrupted (no idea on how this could have happened) and Visual Basic 6 doesn't work properly. The solution has been to setup another machine.
adhoc queries using opendatasource microsoft.ace.olebd.12.0 reading excel file
Everthing was working fine on my local even on production for a long time already "months". As long as the user is a sysad.
And then, just all of a sudden the script using OpenDataSource using microsoft.ace.olebd.12.0 raised an error
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Unspecified error".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
No one is altering the script
No one has updated the server nor my local.
All of the servers for different apps that uses the script encoutered the error.
I'm really confused already on what happened on the driver? Is this some kind of a expiration on the ace driver??
Hope someone could help me.
Do you still have this issue?
Is it a x32 or a x64 server?
Did you install any windows update?
I get this error using AccessDatabaseEngine_x64 driver, and then just installed the x32 driver (no x64 removal) and it worked just fine. The might be a dll dependency or something. Check if you had any windows update regarding these drivers.
Hope you fixed your problem :D
Regards
I am getting the following error trying to connect to a local DB2 instance with Entity Framework using Visual Studio 2010:
SQL1159 Initialization error with DB2 .Net Data Provider, reason code
7, tokens 9.7.3.DEF.2, SOFTWARE\IBM\DB2\InstalledCopies
I have tried to do some research and gotten nowhere, but I assume there is an issue with the DB2 Provider that I am using (I got the newest from IBM). I am able to hit the data if I use IBM.DB2.Data Namespace using the dll from IBM, but I cant hit the database using the Entity Model Wizard.
I dont have a problem hitting this DB from Visual Studio 2008, do I need to download something else other than what I have?
My DB2 Control Center says
DB2 administration tools level:
Product identifier SQL09070
Level identifier 08010107
Level DB2 v9.7.0.441
Build level s090521
PTF NT3297
Thanks for any help
Unless something changed recently, that last I remember you can't use the entity framework directly with the IBM drivers. You need to write the interface yourself to get this to work. As I said, this is what my research turned up a couple months ago when I was researching this.