Because the jdbc odbc bridge is no longer available (see this question/answer), I tried UCanAccess, which works great reading the database, but on Windows 10, throws an error on a write attempt: ([CONCURRENT_PROCESS_ACCESS] - File marked as read only. Notice that only one process (one VM) for time can access in writing mode.).
The same code reads and writes perfectly using the UCanAccess driver on Windows 8.1 and Windows 7.
I am currently unable to tinker since I don't have a Windows 10 system; the tests were performed by a power user on a single Windows 10 install. The mdb file in question was fully accessible by the user. Several path locations for the mdb file were tested (c:\ProgramData, Downloads) with the same result: reads fine, writes fail.
If any Windows 10 user wants to test this for themselves in various directories and possibly manipulating permissions, that would be great.
Here is a link to the mdb file I'm using. Here is a link to the test program (as an exe). Here is a link to the source code.
The test process would be to place the mdb file, then run the test program with the parameter of the path. So at a Windows command prompt, something like:
TestDbAccess c:\my\dir
Where c:\my\dir is where you put the mdb file.
UPDATE: I should have included in the original question that running on actual hardware is what is desired, as opposed to running virtualized in VBox.
UPDATE2: FALSE ALARM:
The mdb file in question really was "Access 97" level, based on byte 20 of the file. The problem was that the component that had the task of creating the mdb file somehow created it as "Access 2000" sometimes and "Access 97" at other times. Exactly how that happened still remains a mystery, but it does not appear to depend on the underlying OS version. My advice to anyone who runs into the CONCURRENT_PROCESS_ACCESS error: believe it!
UCanAccess and Jackcess do not have a problem with Windows 10 per se. I just used UCanAccess to run this SQL statement ...
UPDATE CW_EPG_CAPTURES SET title = 'Win10 test'
... against your sample database (cw_record.mdb, which is in Access 2000 format) on a VirtualBox virtual machine with
Windows 10 Pro Technical Preview, Build 10041 (64-bit)
JDK 7u45 (64-bit)
NetBeans 7.4
UCanAccess 2.0.9.4
and it successfully performed the update without complaint.
The .mdb file was downloaded directly from the link in your question and saved into
C:\Users\Public
Update:
As it turns out, the problem had nothing to do with Windows 10. The issue was simply that an Access 97 file was sometimes being used for testing. Jackcess and UCanAccess just offer read-only support for Access 97 files.
Related
I'm having a strange problem when installing my application on Windows Server 2016. (it runs fine on Server 2012 and Windows 7 to 10 clients).
FYI: I'm a software tester, not the programmer who wrote the code for the app or the installer. We deploy the app as .msi files, if that's important.
The installer for my application does three things:
- it installs all neccessary files, by default into the folder C:\myapp.
- it creates a directory C:\mydir\subdir and in that subdir it creates a file called info.text
- it sets an environment variable called myvar with the content C:\mydir\subdir\info.text
(it can also create a desktop icon to launch the app, but that icon is not important)
The content of info.text is simple plain text: a path where the program can find its database. By default it would contain the path C:\myapp\dbsubdir
This works really well for some decades now and also works fine when installed on Windows 10.
On Windows Server 2016 I run the installer and manually check if C:\mydir\subdir\info.text and the variable myvar are present - and they are. The file info.text also contains the right content.
Then I start the app by clicking the desktop icon and get an error message. I asked my software developer and he said this error message can only be caused by one of two things:
- the app can't find the environment variable myvar
- the app can't find the file C:\mydir\subdir\info.text
After I restart Windows the app starts as if the error had never happened.
On all other Windows Systems I can start the app directly after the installation is completed - my app doesn't require a restart of Windows.
I'm guessing that Windows Server 2016 needs a restart of some kind to be able to read newly created environment variables. But I found no proof for that thought or ideas how to get around that restart.
Is my guess true?
And if yes, is there a way around that restart?
Yes, I've seen this specifically with Windows Server 2016. The restart workaround is to logout and log back in. That seems to force re-read of your environment variables set.
I've a Perl script that forks in order to use Win32::OLE to extract PNGs of slides from a Powerpoint presentation. I'm in the process of migrating it from my old server (Windows Server 2003) to a new server (Windows Server 2012). The script works fine on the old server (which has Microsoft Office 2010) but on the new server (with Microsoft Office 2016), the script bombs with an error about there not being enough storage available:
Win32::OLE(0.1712) error 0x8007000e: "Not enough storage is available to complete this operation"
I've found quite a few references to this error code, but none particularly useful. Whilst this Microsoft support article says what the problem is and what to do to fix it, I have no idea why this is suddenly an issue now I'm moving to a different server and it doesn't seem to apply to my situation.
The new server has loads of spare disk space and RAM, so there should be plenty to go around. (The old server has far less of both, but that still works.)
Could this be something to do with the new server being 64-bit?
Could it be because of the differing versions of Office?
Could Apache or Perl be configured differently by default than when installed on the old server? (It's a new installation of each, but from the same source as on the old server, and I can't find any configuration that limits memory.)
One interesting point that leads me to believe that it's something to do with the script running via Apache (v2.4.27) is that if I run it from the command line (requiring a minor modification), it works fine. Apache runs as a service and I've tried running it as the same user for which it works on the command line, and that has no impact.
I've run out of places to look and things to try now, so any help would be appreciated.
UPDATE (21 August): Since nobody seems to have any ideas, I refactored my code slightly so that it gets called via a scheduled task. That works fine, supporting my theory that it's something to do with it being run via Apache. I'll keep this question open, partly in case a solution is presented and partly in case my workaround can help anyone else who has a similar problem.
We have an old Powerbuilder app running on Server 2000 and need to move it. I am having a problem with moving the Powerbuilder app ver 7.0, to a newer platform - Server 2003.
We basically moved the directory with the app in it and all the Dlls. Then I registered the ones that would allow it. We also had to set up Informix client-side software and verified that it was able to connect to the Database.
The app basically takes 2 parameters then checks for data in a remote database, then generates a return code to be used by another app. The return code we get is unexpected and I have no luck in looking up the number:
-1073741811
The app is run from the command line. When I run the app I get a Windows error that mentions Sybase and msvcr80.dll and a dump, and the return code mentioned above - Here is the error from the manifest text:
Server=watson.microsoft.com
UI LCID=1033
Flags=99088
Brand=WINDOWS
TitleName=Sybase Inc. Product File
DigPidRegPath=HKLM\Software\Microsoft\Windows NT\CurrentVersion\DigitalProductId
RegSubPath=Microsoft\PCHealth\ErrorReporting\DW
ErrorText=This error occurred on 2/14/2013 at 7:56:14 AM.
HeaderText=Sybase Inc. Product File encountered a problem and needed to close.
Stage1URL=/StageOne/cert_lsi_exe/7_0_3_10180/msvcr80_dll/8_0_50727_6195/0001e6d5.htm
Stage2URL=/dw/stagetwo.asp?szAppName=cert_lsi.exe&szAppVer=7.0.3.10180&szModName=msvcr80.dll&szModVer=8.0.50727.6195&offset=0001e6d5
ErrorSig=AppName: cert_lsi.exe AppVer: 7.0.3.10180 ModName: msvcr80.dll ModVer: 8.0.50727.6195 Offset: 0001e6d5
DataFiles=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.mdmp|C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\appcompat.txt
Heap=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.hdmp
ErrorSubPath=cert_lsi.exe\7.0.3.10180\msvcr80.dll\8.0.50727.6195\0001e6d5
I am surprised by the msvcr80.dll request, because this app was written around 2003 and I didnt think that c compiler was at ver 8 yet. I have used Dependency Walker and see no complaints there. I am probably in DLLHell with this thing, though... does anyone have any ideas what to look for?
Thanks in Advance!
I still have a few PB 7 applications around.
Did you try Application Compatibility?
Navigate to the folder and right click on the executable and choose the Compatibility tab.
I suggest trying
Run this program in compatibility for Windows XP (Service Pack 3)
Privilege Level [x] Run this program as administrator
You may need to use Windows XP (Service Pack 2) or an earlier version of Windows.
I have Informix version 11.50 installed on my Windows machine. According to this link, in order to start the server, it should be done through Windows services, look for Informix IDS - instance_name. It is supposed to start when Windows is started up, but for my case it is not, and it wasn't started. Thus I start it up manually by double clicking on it, and it prompt me an error:
The service did not respond to the start or control request in a
timely fashion.
May I know is there any solution in order to start up the local Informix DB on windows?
You will have to check what went wrong in Informix log. It is located in Informix dir and has server name with .log extension (for example c:\informix\ol_test.log). In this file there is information about running server like:
12:42:36 IBM Informix Dynamic Server Started.
Check this file and give us more details if you will not know how to solve reported problems.
Installation of Informix in Windows Vista has been failed. Due to the reason this Informix thing is not able to uninstall and not even allow me to configure a database. Even though I have manually delete the whole folder from Program Files, when trying to install a new copy of Informix, it prompt me the "Invalid ISV name" thing which I totally running out of clue with.
I found a post mention that Vista is not a good platform for Informix. Forget about Windows as a Server a.k.a. WAAS.
xD
I have a watir test that downloads some information from a web app to an Excel file, and I then open the file to confirm the contents. On my dev box everything works fine, but the scheduled automation runs (via Hudson) always fail attempting to open the Excel file. I have checked that the correct version of AutoITX3.dll is registered on both machines (Ruby 1.8, Watir 1.6.5). No other versions of AutoITx3 are registered on either machine. The error on the Hudson box is the one expected if the dll is NOT registered, but it is present in regedit in the same location as on my dev box. Both machines are WinXP.
Running the test manually on the Hudson box results in the same error -- unknown OLE server: 'Excel.Application' HRESULT error code:0x800401f3 Invalid class string.
I searched for similar errors and saw one instance where running on a virtual machine had caused similar problems, but only if the VM window was closed. I don't think this is a code error since it runs on the dev box. Any suggestions for debugging this?
TIA,
Sabrina
I find the use of Excel to be an antipattern in test automation. I know a lot of people like it, but if you're using that for automation then there are simpler ways to go about it. Consider using CSV with FasterCSV for the automation tests and checking anything into version control which I'm assuming you're using.
IMHO, you should only use Excel when a human is involved - i.e. you may a series of tests defined in CSV, but you edit them in Excel, save back and then diff against what's in a source control system, storing it as CSV.
Excel is useless to diff, so it doesn't store well in a source repo, there's no reason to install it on a CI box when CSV will do and do better.
That's my 2 cents anyhow. :)
Cheers,
Charley
I would do another search for the issue and leave Watir out of it. I can find several issues for 0x800401f3 associated with FoxPro, Perl, and Oracle.
Have a look at this article http://support.persits.com/show.asp?code=PS01032622
It names the possible causes for your error code.
bq. This error means that either the component has not been registered on the server or the ProgID passed to the Server.CreateObject method is misspelled. On Windows 2003 and XP, it may also mean a permission problem on a system registry key.
I think for you the last one is relevant:
bq. On Windows 2003 and XP, it may also mean a permission problem on a system registry key.
BTW, I googled for ":0x800401f3 Invalid class string." and this was the first result.
What are you trying to test?
That user can open downloaded file with Excel? How do you verify that automatically? With screen shot?
Or that some data is in the file? In that case I would verify contents of the file with something like roo.
I finally figured it out. What I thought was a working Excel install on the remote machine was instead the free Excel reader, which does not have the API hooks WIN32OLE looks for in the registry. Installed the full Excel program and now everything works. I knew the Universe would be consistent!