I have been using MS access database ( *.MDB) in a 64-bit format in windows 7 (64-bit) for quite some time. The Access SQL is called from a C++ module.
I have recently upgraded my OS to windows 10, I am still able to open connection to the ODBC (user DSN in this case), however, it seems my earlier program can no longer open the table or run queries. I am unsure what are my options now, please advice.
Should I use .accdb in place of .mdb ?
Try changing provider in connection string : "Provider=Microsoft.Jet.OLEDB.4.0;" Like this if not yet done so.
After testing I found that changing from .mdb to
.accdb did solve the problem. I am posting so that I can close this thread and perhaps benefit someone.
Related
We're currently facing some issues trying to start a Service in Windows, which is an executable file and the output of a compiling process using .NET framework for C++ (Windows\Microsoft.NET\Framework\v2.0.50727).
We are able to compile, start and execute the exact same service in our DEV Environment, which consists of Windows 7 installed in Virtual Box with VisualStudio2005 (it's old software, I know...).
When we do it in our Test environment, we get a timeout error when trying to start the Service (1053: The Service Did Not Respond to the Start or Control Request in a Timely Fashion.). The server is running WindowsServer 2008 R2 Standard. We already tried to change the timeout time, without success. We also compiled the source code using the same Visual Studio 2005 SW and although we were able to compile it successfully we are still getting the same timeout message.
We are currently trying to understand what's objectively causing the different behaviour. The most obvious difference is the windows version, naturally, but since the compilation output appears identical and there are no errors during the compilation process in both environments and both output logs are identical as well we are running low on ideas to identify and validate objective differences. Our latest approach consists in trying to understand if by using Dependency Walker (dependencywalker.com) we are able to identify any issue regarding DLLs (we also checked if there is any corrupt DLL or system file in the environment and there isn't any, using the windows command for it). We're also checking some of the suggestion made on the following post: Error 1053 the service did not respond to the start or control request in a timely fashion.
Any one faced a similar issues? If so, can you suggest any kind of approach to identify the reason why the service isn't staring, other than the ones here mentioned?
Thanks in advance.
We ended up extending the timeout time regarding Service startup in Windows to 10 minutes followed by the necessary restart and we managed to start the service normally and almost immediately, which makes us think that the timeout time was never really an issue here. Although we haven't been able to pinpoint the exact cause we are still inclined to think that it was a Windows/Server related issue.
I have a c++ application which uses occi for connecting with database. I am using occi connection pool mechanism. Recently I have got an error ORA-00257 and it looks like after that nothing is working.
Can you please advice how to handle ora-00257 using occi?
Did you even try to google ORA-00257?
First match:
"How to Fix ORA-00257: archiver error. Connect internal only, until freed. A very common Oracle database error that is basically telling you that you have run out of logical or physical space on the mount, disk, or your db_recovery_file_dest location that holds your archivelogs."
I am trying to enumerate Windows power plans through very straightforward code that has been working for several years. On my Windows 10 64-bit machine, however, I am getting errors when I try to enumerate a collection of power plans.
I realize Visual Foxpro code is like a fossil, but it is still pretty easy to read:
loSchemes = CREATEOBJECT("Collection")
loWMIService = GETOBJECT("winmgmts:\\.\root\cimv2\power")
loItems = loWMIService.ExecQuery("SELECT * FROM Win32_PowerPlan")
FOR EACH loItem IN loItems
loSchemes.Add(loItem)
ENDFOR
The code has been working for years, from Windows XP up through (I think, anyway), Windows 10.
The error happens after loItems is instantiated via the ExecQuery() method call. The object exists and has visible properties, but if I try to access anything in the debugger, it says the expression cannot be evaluated. If I wrap the iterating FOR loop in a TRY..CATCH, the error I get is:
OLE error code 0x80070668: Only administrators have permission to add,
remove, or configure server software during a Terminal services remote
session. If you want to install or configure software on the server,
contact your network administrator.
So, it looks like I am being locked out from power plan information because the process thinks I am remotely trying to change the configuration even though I am accessing WMI data from the local machine (where I do have administrator rights, incidentally).
I downloaded a "WMI Explorer" tool from Code Plex, and I actually get the same problem there when I try to iterate over Win32_PowerPlan. The log returns an error:
Failed to enumerate instances from Win32_PowerPlan. ERROR:
(That is the literal response -- no actual error is listed.)
This makes me think this isn't just some sort of Foxpro issue.
Edit
I downloaded a WMI process explorer from Sapien, and it displays a UAC prompt every time it starts, running it with elevated privileges. Both the 32-bit and 64-bit versions of that software can query Win32_PowerPlan and display results. I then ran the Code Plex WMI Explorer as administrator and it was also able to iterate over Win32_PowerPlan without errors. So, the issue appears to be unrelated to "bit"-ness and has everything to do with WMI data access requiring administrator privileges even though I am running locally using a login that does, in fact, have administrator privileges. Needless to say, I am still stumped... For the record, I can still access all sorts of other information via WMI: processor info, memory usage, processes, services, IP Address, and OS description. All of those modules still work perfectly. But when it comes to the \root\cimv2\power namespace and accessing power plans, no joy.
Further edit
Some other questions mention ImpersonationLevel, saying I might need to explicitly set the level to "impersonate" (an enumeration constant = 3). I am playing with my WMIService object and can read and write the impersonation level, but it is 3 by default. I raised it to 4 ("delegate") and still cannot access the power plan items. The query runs fine, but an error gets thrown when I try to access any properties of loItems. If I reduce the impersonation level to 1 ("anonymous"), then an "Access denied" error gets thrown on the ExecQuery() call. Finally, level 2 ("identify") allows the query and I can access the Count property without an error being thrown. But zero items are returned where there should be 5. I am confused now more than ever.
In summary, I cannot access power plan information from my local machine, even though I have administrator privileges, regardless. This is on a Windows 10 Professional 64-bit installation (all updates up-to-date), definitely no Terminal Server software installed.
Where can I obtain high quality information about ODBC & Access Databases?
I have worked on various projects over the years using ODBC from MFC/C++/Java.
Currently, I have a project in C++/MFC that uses a customized MFC layer to interface dynamically to an ODBC DSN connected to an Access 2000 dbm file.
This generally works.
However, I commonly get warnings such as:
DBMS: ACCESS Version: 04.00.0000 ODBC Driver Manager Version:
03.80.0000 Optional feature not implemented State:S1C00,Native:106,Origin:[Microsoft][ODBC Microsoft Access
Driver]
Warning: Driver does not support requested concurrency. Optional
feature not implemented
State:S1C00,Native:106,Origin:[Microsoft][ODBC Microsoft Access
Driver]
and now, I get the following when our software attempts to create a view:
General Warning Unable to open registry key 'Temporary (volatile) Jet
DSN for pr ocess 0x18fc Thread 0xc0 DBC 0x8c4cfc Jet'.
State:01000,Native:1,Origin:[Microsoft][ODBC Microsoft Access Driver]
DBMS: ACCESS Version: 04.00.0000 ODBC Driver Manager Version:
03.80.0000 Executing SQL: create view SPEC as select CALNAME as TEST, CARDNUMBER, CARTONSTYLE as CARTON, CCAL as FLUTE, CORRDIR,
CUSTOMERID, DESCRIPTION as DESCRIPTIO, DESIGNER, DESIGNNUM, JOINTSIZE,
JOINTTYPE, PANEL_D as DEPTH, PANEL_L as LENGTH, PANEL_W as WIDTH,
RULRULX as DSIZEX, RULRULY as DSIZEY, SHEETUX as SIZEX, SHEETUY as
SIZEY, SHEETX as GROSSX, SHEETY as GROSSY from "Designs" where
DESIGNNUM is not null
Warning: ODBC Success With Info, Driver's
SQLSetConnectAttr failed State:IM006,Native:0,Origin:[Microsoft][ODBC
Driver Manager]
General Warning Unable to open registry key 'Temporary (volatile) Jet
DSN for pr ocess 0x18fc Thread 0xc0 DBC 0x8c4cfc Jet'.
State:01000,Native:1,Origin:[Microsoft][ODBC Microsoft Access Driver]
For the first part, regarding warnings concerning optional feature not implemented, and concurrency state not implemented (perhaps the same underlying issue), I have no idea what concurrency feature my software is even asking for? What concurrency states are appropriate? How does one ask for the "correct" one? Is there a table for versions of Windows vs. appropriate concurrency state to request?
For the second part, regarding the specific failure to create a view due to failure to open a registry key: huh?! Who is failing to open what registry key?
I have found some information concerning the need to give IUSR full permissions on the "windows NT temp folder". This sounds like a horrible issue for a desktop application to need to concern itself with. How should a desktop application, using an ODBC DSN ever need to concern itself with user permissions when manipulating a database file which exists in a user read/write-able path? What more permissions are necessary to allow the user to execute this SQL? And since the user is already able to add and delete columns and rows in the existing tables in the database, what more needs to be done?
This code used to work under XP. So I have to assume that Vista and/or Win 7 added some security that now blocks this functionality.
I am interested in:
Canonical reference material from Microsoft that actually documents their various ODBC Access interfaces, options, versions, host-issues, etc.
Specific information regarding the warnings regarding concurrency.
Specific information regarding the apparent permissions failures when trying to create a view in the access 2000 dbm.
Suggestions for modernizing the above, sans a complete overhaul or technology replacement. i.e. I would happily update the Access file to 2003 or 2007 or whatever, or possibly switch the back-end to SQL Server Lite, but I cannot justify changing from ODBC to some replacement middleware (it's just not worth the time & risk).
Thanks for any ideas or help you may have to offer.
we have an application that dynamically make use of ODBC access databases.
Microsoft has good documentation about odbc
http://msdn.microsoft.com/en-us/library/s9ds2ktb(v=vs.80).aspx
You should also take a look at the CRecordset and CDatabase documentation
http://msdn.microsoft.com/en-us/library/1hkkwdf0(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/2dhc1abk(v=VS.80).aspx
For the concurrency issue, it often occurs when you open a CRecordset with the wrong options. Where I work, we usually open recordsets with the following options
RecordsetToUse.Open(CRecordset::dynaset, "SQL Statement or NULL to use the DefaultSQL", CRecordset::skipDeletedRecords);
If using the recordset for fast readonly access, you can also use
RecordsetToUse.Open(CRecordset::forwardOnly, "SQL Statement or NULL to use the DefaultSQL", CRecordset::readOnly);
3 . For the Create View problem, It seems that ODBC doesn't support the creation of views... I think, on the other hand, that you could use ADODB (http://www.codeproject.com/KB/database/adoclasses.aspx) to do that
Yeah, the migration of remote clients can be a pain. Part of the reason why I absolutely try to avoid Access at all costs. I've done this one of two ways.
Use WebEx (or some other online meeting program) to grab control of the remote machine to insure the migration goes as needed.
Build into the new code a check to see if database has been migrated.
If the new DB (SQL Server) shows as not found, then the app fires off the migration tool. However, this means building and perfecting a migration utility and scripts to automate the migration as nay number of things can go wrong.
One thing I did start doing a while ago is building an app compatibility table into the DB. That way the code can check to make sure the DB schema version matches. I also include another table (encrypted) with all the necessary SQL to upgrade (migrate) the DB to the new version. That way, the app can determine that the DB needs to be migrated and can run through the scripts to do it.
I really hope this helps.
From what I understand, the output from the following script should include "Win32_PerfRawData_PerfDisk_PhysicalDisk" in Windows XP and higher, but it doesn't for me in Vista Business 32-bit Service Pack 2. Thus far I have been very unsuccessful googling for information about this performance class.
strComputer = "."
Set objWMIService=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\cimv2")
For Each objclass in objWMIService.SubclassesOf()
Wscript.Echo objClass.Path_.Class
Next
Does this WMI class simply not exist in Vista? If it is just me, is there a way to fix WMI? I have already tried running winmgmt /resetrepository and winmgmt /resyncperf and neither helps.
Edit: Sorted and Edited Output
snip...
Win32_PerfFormattedData_NETFramework_NETCLRSecurity
Win32_PerfFormattedData_Outlook_Outlook
Win32_PerfFormattedData_PerfNet_Browser
Win32_PerfFormattedData_PerfNet_Redirector
snip...
Win32_PerfFormattedData_PerfDisk_* is missing.
Also tried lodctr /R. No help.
SOLVED
These counters can be disabled in the registry. Just set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters to 0 and reboot.
http://blogs.technet.com/askperf/archive/2010/03/05/two-minute-drill-disabled-performance-counters-and-exctrlst-exe.aspx
Should be okay on Vista. the docs here state at the bottom of the page:
DLL: Wmicookr.dll on Windows Server 2003 and Windows XP, WmiPerfInst.dll on Windows Server 2008 and Windows Vista.
Can you check that the WmiPerfInst.dll DLL exists on your box?
Another things to try is to see if you can get stats from the corresponding RawData class? Vista appears to have changed the way in which raw data is translated to cooked data. My knowledge of that is pretty thin (based on a very cursory Google search) since I'm only involved in WMI on XP/Svr2k3/Svr2k8 - I didn't think anyone was actually using Vista :-)
And, if you're going to accept my answer even though it didn't help, at least let me plagiarise your solution :-)
These counters can be disabled in the registry. Just set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Perfdisk\Performance\Disable Performance Counters to 0 and reboot.
But seriously, thanks for that. At some point, we'll probably have to support post-Vista ourselves so it'll help us out to know this.