I am trying to install BDE Engine by executing the following command line from my installation program as follows.
ShellExecute(0, nil, 'regsvr32.exe', 'BdeInst.dll', nil, SW_SHOW);
It pops up with a message requesting permission to install BDE Engine at a particular location. When you click okay button, it pops up another a message as follows.
I did verify that I have plenty of free space in my hardrive. When you click on Yes button, it installs the BDE engine successfully.
I don't know why. Plus, there is not much information online about this.
Any input will be greatly appreciated.
First of all, the BDE is deprecated, and you should better avoid using it, even with other versions of Delphi.
You have third party components around able to connect directly to DBs without using the BDE. See e.g. DevArt, SQLDirect, DASoft (its FreeDAC is free), and a lot of other components like Zeos or our SynDB Open Source libraries.
You reached the well known "2GB rounding error". The BDE installer suffers from it, but applications using BDE also.
BDE installer is buggy.
It just does not work with newer versions of Windows.
You have other installers around, like interbase and BDE on windows 7 or Bde Installer on these Embarcadero days
BDE used in applications will suffer from the same 2GB limitation, linked to the GetDiskFreeSpace improper use.
There is a work around available on Embarcadero CodeCentral which is worth to be included in your application code.
The BDE is an old piece of software that has now been deprecated for a few years. While people do still have it running, I believe it was originally 16bit software and may never have been changed. I have a feeling the message is coming from some piece of software that can not understand your large hard drive. I don't recall if BDEInst.dll is the BDE installer from Borland, but the message may be coming from that. You also mention an "Installation program is being developed ...".
It should install to XP, and I would get it working there first. Win 7 and 8 introduce more issues. However, if at all possible, reconsider if you want to install BDE at this point in time.
The bdeinst.dll uses the Win32 API function GetDiskFreeSpace, which can report a completely misleading value when executed against a drive that is larger than 2GB - see http://support.microsoft.com/kb/202455 for a developer-based workaround.
The reason I know this is because I've been hit by it before and examined the imports for the bdeinst.dll binary which indicates that it uses GetDiskFreeSpaceA (this is the ascii version of function).
If you have to use the BDE, then you just have to accept that you may see this error when you attempt to install the app
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 was tasked to set up an open-source icap-server to scan files that are uploaded in one of our web applications.
The files base64-encoded withing the upload method and this seems to lead to the fortigate not being able to scan it properly.
Now I managed to set up an icap-server using "c-icap" and tested it with "clamav". So far it seems to work, at least EICAR files are detected.
Now the problem is, that my boss is basically a "Windows-only" person who says that any open-source AV can´t be trusted enough.
He wants me to try to have the requests/uploads sent to the c-icap server, but scanned with Windows Defender. ß Is there any - useful - way to accomplish this? Also, since I am super new to ICAP - are there any restrictions regarding which icap-server can be used?Like, is there any way to force requests to be handled with a metadefender-icap only, and not any other icap server?
Sorry if these questions are a bit unspecific and basic, but just started with ICAP yesterday!
Thank you!
Check out this link: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/metadefender-icap-with-windows-defender-antivirus-world-class/ba-p/800234 to see what Microsoft offers regarding Defender+ICAP.
I have used commercial ICAP solutions in the past (like Bluecoat) that allow plugging in multiple commercial virus engines (Kaspersky, Sophos, ...).
These are appliances, and you don't need to tell your boss their internals are probably some sort of Linux ;-)
You can probably also set up a commercial antivirus solution on your Linux system and use that.
Looking at this link: https://learn.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/microsoft-defender-atp-linux it may even be possible to run Microsoft's Defender on Linux. I haven't tried it myself though.
Unlike your boss, Microsoft realizes software shouldn't be made to just run on Windows anymore (even MS-SQL Server now runs on Linux).
I have written an application to control a merge replication process on a sql server. It is running on my development machine with no problem. On my test install I have installed a SQL Server 2008 R2 64 bit on Win 7 64 bit. When I try to use my replication program it crashes with the following exception message
[ReplicatorClient.exe] - [Fatal] - [1/15/2015 9:29:56 AM] - Version 0.5.16.0 User - vuser Message - Could not load file or assembly 'Microsoft.SqlServer.Replication, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Stack Trace -
at ReplicatorClient.Models.DatabaseSynchronization.CreatePublication()
at ReplicatorClient.ReplicatorWindow.ReplicatorWindowViewModel.MenuCreateSubscription()
I have copied the Microsoft.SqlServer.Replication.dll that I am using into my bin folder on my developer machine and am installing it in the program folder on the test machine but the program is obviously not seeing it. What steps can I take to figure out what I need to do so this dll can be seen and my application can work correctly when deployed?
I am using WIX to install this.
In general it doesn't really matter then WiX / MSI is your deployment method (as evidence by your manual copy) as it's really a matter of getting the right dependencies automated.
In general you have to profile the assembly load. I always hated this message because it says X or "on of its dependencies". I wish it would just tell me which exactly it is.
You bust out ILDasm and ProcessMonitor to get an idea of what it's trying to load and failing on. Get it (or those) into the installer, reset the VM and rinse and repeat.
PS- sometimes private deploying DLL's is the right thing to do and sometimes installing a prereq redistributable is the right thing to do. There may be a SQL MSI that handles all of this for you and just wire that into your bootstrapper / chainer (if you have one yet) instead. It just takes a bit of research. This isn't a DLL I'm familiar with so I don't have an answer off the top of my head.
We have a higher-end Win7-64 Dell precision workstation notebook with an i7, 8 gigs of ram, tons of hd space and running dedicated AMD graphics. The machine is about a month old. It was one of the highest-end we could get at the time.
What we're experiencing is when we run our WPF/SQL Server (local) app, it tends to hang and stall, sometimes completely crashing, but mostly just hanging until we force it to close. However, the exact same installer running in a VMware virtual machine running on that same machine runs flawlessly. Actually, the VM install runs better than a lot of native installs on other machines. It's very snappy with no hangs or hesitations at all. But again, same app, same installer running direct in the OS, and we're back to the issues above.
We've ran all Windows updates.... we've tried completely reinstalling everything... .NET frameworks, SQL Server, video drivers, even updated the BIOS and checked for rogue services but it still happens.
At first we thought it was Symantec AV's real-time protection because when we first shut that off, things started getting snappy again (and slowed down and froze when it auto-re-enabled itself furthering this hypothesis) but then it just started slowing down again, and more surprising, that same AV is running in the VM without issue! Checked the exceptions but there weren't any.
We even tried forcing WPF to run in software-render mode but again, nothing.
Now the odd thing is this only seems to be happening on this and a few other machines, but we can't seem to find anything in common except they're all running Win7 64-bit. As such, we have absolutely no idea where to start. And since most are hangs, not crashes, we can't even look at the crash reports.
So can anyone give us any idea what else we can look at? This is holding up us shipping a three-years-in-the-making major release of our software so to say this is a show-stopper would be an understatement. We've been stumped for about a month now and getting nowhere fast.
Found it!! Turns out there's a bug in .NET 4.0 regarding UI Automation and the changes MS introduced. Here's the info, and the fix! (Note: Even if you call MS, they will send you a link, but it's always a broken link. I managed to track this down manually.)
Note: Their article talks about a specific case that causes this behavior, but if you google around, you'll see tons of issues around hangs related to those DLLs. The latest is they're promising a fix in the .NET 4.5 runtime (from a MS post on this issue.)
Here's the KB article...
http://support.microsoft.com/kb/2484841/en-us
...and here is the actual hotfix.
http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
Apparently the VM didn't suffer from this. We weren't sure if the VM had the hotfix applied or not or if this only happens on non-virtualized machines. Still, this solved all of the issues and the app is now snappy again. (Man, was this fun to track down! Ugh!!)
I am running my development environment Windows XP. I need access to the function SHGetKnownFolderPath. My team proposes that I simply update my shell32.dll with theirs and update my header files.
The function is documented here:
http://msdn.microsoft.com/en-us/library/bb762188%28v=vs.85%29.aspx
Now, understand that the focus of this question is on the viability of overriding/updating the shell32.dll manually via copy-paste. Please do not respond with workarounds/alternatives to the function mentioned above. That is not the point of this question.
Is it safe to simply take the Windows 7 version of shell32.dll and paste over mine (in XP)? I am afraid to test that for fear of murdering my entire operating system. I do not know all of Windows' library inter-dependencies and whether this would even be compatible. It sounds incredibly unstable, but that is what is being proposed I do.
You should not change a Windows DLL manually. A Windows 7 DLL will have dependencies that will not resolve on XP. Even if this worked (very unlikely), next time you install a patch from Windows Update it may either break due to dependencies or replace your Windows 7 DLL back to XP version.
UPDATE: This just won't work. The Windows 7 DLL has dependencies on API sets which did not exist in XP.
Copying manually the dll via copy-paste will not work, because WFP will kick in and restore the original dll. IIRC only digitally-signed updates from Microsoft are allowed to replace system dlls on a running system to avoid messes like this. You should replace the file offline (e.g. from another copy of Windows/BartPE/Linux/...), or disable/workaround WFP in some way. So, it's not practical.
Taking a system dll from another version of Windows and copying it there seems like a terrible idea. The shell changed a lot from Windows XP to Windows 7, I'm sure that there will be a lot of missing dependencies. Even if you managed to copy every file of the Windows 7 shell to Windows XP, these files would depend from newer user32/gdi32/ntdll/... functions added in Vista and 7, so it would not work anyway.
So, I think that the most probable consequence of replacing shell32.dll would be the failure to load almost any non-core component of the OS: failing shell32.dll to load due to missing dependencies, almost any GUI executable that links against it would fail to start. So, it's not safe.
Other than being a problem from a technical standpoint, I strongly suspect that it's also illegal. Having a license for both Windows XP and Windows 7 would not help, I think that this is considered "modification of the software product", that is explicitly disallowed by the Microsoft EULAs. So, it's not legal.
If you want backwards compatibility with XP just use SHGetFolderPath instead of doing all this mess.
Is it safe/practical to manually update shell32.dll in
Windows XP?
No.
shell32.dll is a core operating system file. I would expect that minus the other dependencies underneath the Windows 7 version you would have all sorts of unexpected behaviors. It would be better to test within a VM a complete Windows 7 environment rather than copy over a part of another version of an operating system.
Bigger questions: Do you think anyone at Microsoft every tested this exact combination? If you run into issues and you call support do you believe that you will find that your configuration is a supported one for your efforts? Having worked for MSFT in the past I would think that the answer to both is likely not.
Probably they know what they're saying. Anyway I would suggest you creating a system restore point and, just in case, downloading a minimal linux distribution so that, in extreme cases (i.e. windows can't boot), you simply restore their shell32.dll with yours.
I don't think so...
But if still want to try, then i suggest you install a virtual machine and try it there. this way much safer.