Whenever I open one of the Quantum Grid demos in Delphi XE Pro (on Windows 7 32-bit), the following error is displayed for every table (I think) in the project:
error message http://www.tranglos.com/img/qgerror.png
The message is:
Network initialization failed.
File or directory does not exist.
File: C:\PDOXUSRS.NET
Permission denied.
Directory: C:\.
I understand permission issues writing to c:\, but the result is that while I can build and run the demo projects, no data is displayed, which makes the demos rather useless. And what kind of database writes its configuration to c:\ directory in the 21st century anyway? :) (Yes, I know very little about Paradox databases, but I won't ever be using one either. I just want to learn how to use the grid.)
Using BDE Administrator I've tried changing the Paradox "NET DIR" value to a folder with write permissions on the C drive. Result: now the database tables cannot find their data:
Path not found.
File: C:..\..\Data\GENRES.DB.
...and the unhelpfully truncated path gives no indication where the files are expected to be.
Is there a way to work around the problem so that the demos can load their sample data correctly?
Did you install the BDE correctly? It should use the DBDEMOS files. Do you see such an alias in the BDE administration utility? Can you open that database in one of the Delphi demos?
The BDE is not a XXI century database, it was developed twenty years ago and never upgraded lately. It's an obsolete tecnology, but because it comes still with every release of Delphi with a known database it is still often used in demos because nothing new has to be installed.
Anyway that file is not its configuration file. It's a sharing lock file to allow more than one user to use the database concurrently. Because it is a file based database without a central server, it has to use such kind of shared files. Usually its position is changed to a network share, but it defaults to C:\ for historical reasons.
Anyway it's not only the BDE still attempting to write in the prong directories. I still see a full bunch of applications attempting to write to C:\ (especially logs) or other read-only positions.
Using BDE Admin to change the location for PDOXUSRS.NET helped, but it wasn't sufficient. DevExpress did the right thing in specifying a relative folder for the data location, and the relative folder seems perfectly allright, but for some reason the DB can't find it.
Solution: under the \Demos\ folder find all the *.dfm files that contain the string
..\..\Data
and replace that string with the absolute path to the demos folder. That done, all the demos open correctly.
I know this message from our own applications. It has to do with security measures introduced with Windows Vista. The operating system trying to protect critical files denies access to them. There is a method how to bypass this mechanism without compromising security. Try to run your application in compatibility mode. When application is running in compatibility mode, read / write operations from / to system folders are redirected to "safe" directories located in C:\Users[Current User]\AppData\Local\VirtualStore.
More info on http://www.windowsecurity.com/articles/Protecting-System-Files-UAC-Virtualization-Part1.html.
Related
I am trying to open an MS Access database in Base using the instructions here . (I've tried both .mdb and .accdb)
I can follow the process described by Gord with no problems until the last step, where it asks me to save the database in LibreOffice format. I choose a filename (say mylinuxdb.odb), click OK, and then Base opens with this error:
The connection to the data source "mylinuxdb" could not be established.
org/apache/commons/logging/LogFactory
Note that it is complaining about the new .odb database, not the MS Access database. Nonetheless, no data is imported.
Can anyone help with this?
Thank you.
Revised answer:
It appears that this issue is specific to distributions like Linux Mint that install LibreOffice Base by default. Presumably in order to enable embedded HSQLDB databases they also install a rather old version of HSQLDB which conflicts with UCanAccess. To fix that, remove LibreOffice's copy of HSQLDB. For Linux Mint that would be
sudo apt remove libhsqldb1.8.0-java
(original answer)
I was able to reproduce your issue with LibreOffice 6.4.6.2 on Xubuntu 20.04. It looks like the setup instructions on Ask Ubuntu may need to be tweaked.
In the meantime try opening your .odb file, clicking through any errors. When Base opens, choose
Edit > Database > Properties …
and notice that the "Database URL" text box has "jdbc:" in front of it.
so if the textbox contains
jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
then apparently Base will try to use
jdbc:jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
and that won't work. We need to have just
ucanaccess:///home/gord/Documents/Database1.accdb
in the text box (as in the screenshot above).
This is NOT (as per chosen answer) "specific to distributions like Linux Mint that install LibreOffice Base by default". Such statements should be avoided as they are clearly very difficult to prove except with rigorous analysis of all other situations, which is clear was not done and in practical terms cannot be done.
I just encountered this message with an LO Base form which uses a MariaDB installation on Windows 10, using a JDBC connection with the mysql-connector-java-8.0.28.jar connector .jar. The form was created only minutes previously.
Interestingly, I happened to have a Python application running at the same time but, and I stress, this Python application does not use any kind of connection to any mysql database whatsoever. Nor, being CPython, does it use Java in any way whatsoever.
I find that when I close the Python application I am then able to open the LO Base form. Furthermore, after having first opened the LO Base form I am then able to run the Python application.
As to why this ludicrous error should arise in these circumstances in the first place, I do not yet know. Chalk it down to yet one more LO anomaly and oddity around which you have to navigate by hook or by crook.
I have created a GUI and Database for my company. I am trying to alpha test the program. I made the program so that everyone would place it on their C drive so that the file paths would stay consistent. When I email the zip folder to everyone it adds an extra folder that is causing errors to the file path (I believe the error occurs during extraction?). Does anyone know a good way to prevent this from happening? Thanks!
Although "xcopy deployment" is a valid method to deploy programs, it can come with complications, as you have discovered. Instead, you can create an actual installer program which is much more versatile.
For a lead-in on making an installer you can read Create MSI installer in Visual Studio 2017.
Make sure that the program uses locations as given in the Environment.SpecialFolder Enumeration so that it is automatically adapted for any (properly-configured) Windows installation.
Other installers are available, e.g. Inno Setup, which may offer simpler or more detailed configuration of some options like replacing or keeping older files, or installing prerequisites like a required framework version.
Is anyone aware of a known issue (and workaround) where it seems like Rational ClearCase will corrupt a Microsoft Project file if it is checked out and the network connection changes? I have a laptop that is docked and hardwired to local network most of the time, and I perform some work with the Project file, then I will undock the laptop to go to a meeting or home for the evening, and upon re-docking, the Project file can no longer be opened and appears corrupt.
The error message shown is "Project cannot open the file. -Check that the file name and path are correct. -Check that the file format is recognized by Project..."
There doesn't seem to be anything directly related to Microsoft Project Server regarding ClearCase on ibm.com.
I have seen issues with dynamic views, when the view server is on the network (and said network is abruptly cut).
If this is your case, I would recommend using snapshot views.
You can have similar issue with ClearTeam 8.x web views (since the latest versions support dynamic views)
Regarding snapshot views (meaning files directly on your hard drive), you only need to watch for concurrent processes that might still access your file when undocking. A program like procmon can help.
I have a legacy VB6 system which is installed in C:/Program Files/IronDuke
In the past it has written some files into this directory. I understand that these files are hidden away if the application is installed under Vista or a later OS, but not if they were written under XP or earlier OS.
How can I retrieve a copy of these 'hidden' files when written under Vista or Windows 7 or 8?
You are looking at a feature called UAC Virtualization, this blog posting gives a pretty good rundown on what is happening and where the files are located.
From above article:
For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.
so in your case if you are trying to find the files you need to look in:
C:\Users\Username\AppData\Local\VirtualStore\Program Files\IronDuke\
You cannot write to Program Files under Windows 7 / 8 - system security prevents programs running as regular users from doing so. One option for you is to write these files to the user's profile folder (you'll have to update the VB6 program for this, although the changes should be pretty small if the program is otherwise well-written). This would be your best option since the updated code would work well in the future without more changes.
You amy be able to get the program running using Compatibility Mode but I doubt it - on my Windows 8 system I don't even get 'Windows XP' as a compatibility option anymore. All other options will likely enforce security.
You can try running your program as administrator but I'd only do this if you don't have the source to make the changes - it's poor practice to run programs with all privileges since it opens up the system for attacks.
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)