Lately I am having some very weird problems and I can't exactly pin out what is causing it.
I've got an Access frontend application which uses SQL Server linked tables. A few days ago I deployed a new ACCDE version which caused some very weird problems.
At one computer I was unable to open a form from the Ribbon (some 21~ ish error can't exactly remember but it was a default open-form error). After some investigation I found out that the problem is caused by an allow additions = false line on the on-open event of the form. This however is very strange since it has always been there. Besides that, at almost every other computer, including mine, it just works fine while the code (and forms, queries, etc.) are exactly the same..
When trying to open the same access file in accdb at that specific computer it does seem to work (opening being done with runtime version).
So as workaround (for the time being) we made sure that that this computer opened the file as accdb while the others (where it did work) opened it as accdde.
Today however it went wrong again but on a different computer and a different issue. Now a completely other form doesn't load it's data (it's empty). Testing it locally it works fine however and testing it yet again on another computer (with also a runtime version) it also opens fine with data in it...
The weird thing is when using an older file (a few application versions back) just works fine but the current one doesn't, at least not on all computers. This makes me believe that the file is corrupted but the weird thing is, why DOES it work on some other computers? If the file would be corrupted you would say that it is causing the issues on all the computers?
So the next thing I thought of was different Access runtime versions. I tested 4 computers (two where everything works fine) and the other 2 have issues.
Computer one (which works fine) is a 32 bit system with Access runtime version 15.0.4841
Computer two (with issues) is a 64 bit system with Access runtime version 15.0.4569
Computer three (also with issues) is a 32 bit system with Access runtime version 15.0.4833
Computer four (my own computer tested against a local db) is a 64 bit system with Access runtime version 15.0.4849
So the computers where the Access file doesn't work all have a lower version than the ones that do work, is it possible that this is causing the problem?? If it is, I still wonder why the older Access application file works on all computers but the current one doesn't..
On a side note:
Also tried to repair the access runtime version on one of the computer where it didn't worked but this had no effect
Doing a Compact & repair on the Access file itself also doesn't have any effect
Well, you plain and simple cannot run an x32 accDE database with the x64 bit runtime – it simply will not work.
And if the runtime versions are different on those target machines then you want to un-install the runtime, and download the latest version. Windows update will NOT update the runtime. With runtime 2010, you had to download + install runtime, and then ALSO download an update to the runtime.
With 2013, then the latest download of the runtime will always include the latest SP updates.
Attempting to run Access with different runtimes will in general be a disaster. And in the case of attempting to use the x64 bit runtime on an application compiled to x32 will not work at all.
I would also before you compile to an accDE check and remove any and all references not required. So references to word, excel or anything else should be removed and late binding should be used.
Regardless, you want to ensure that all computers are using the same runtime version, and this includes the bit size. So in all cases you want to ensure and use the x32 bit runtime, and then ensure that all machines are running the same version/revision of the runtime.
Related
I made a project in VS 2022 using vb.net. It worked fine when I ran it from VS (Debug x86 local machine). I published it and it produced a msix upload file with no errors or problems. I then copied the code, xaml and assets to another project with a slightly different name. I ran it from VS and it ran fine, like the original I had copied from. When I published the second (remember, identical copy), it produced hundreds of errors mostly about file names that are the same but sizes are different. I reloaded VS and published again with no other change. This time it produced hundreds of errors of the "System.void not defined" kind, every line of code was an error. It is difficult for me to believe that this is not an error in VS because I did exactly the same thing and got different results. Any thoughs or solutions please?
I get this error some 23 times when publishing the website. There are no issues with compilation and testing. I know someone is going to have the urge to say "remove the duplicate reference from the web.config" but that's not the problem here. This is a project started in 2008 and the use of ReportViewer predates the code being added to our git repository (which in turn predated me working on it) so I know that nothing is technically wrong with the code. In fact, until last week, it published just fine. What changed? I finally got a newer, faster computer. The client wanted one line removed. I put the code on the new computer, removed the offending line, built, tested. All is ok. Then I went to publish and got the ReportViewer error. I'm working with a byte-for-byte copy of the project on the old computer and the only thing that fails is the publish on the new computer.
Clearly something isn't installed on the new computer that's preventing publish, but I don't have a clue what it is. (Or possibly something installed that shouldn't be. The "new" computer was actually in-use by another developer.)
I was grasping at anything for this problem. I got the idea to remove all copies of the ReportViewer DLL from the Microsoft.ReportViewer.WebForms folder. There were 5 different versions. Windows itself balked when I tried to move version 10. That was my clue. It turns out that whoever switched from version 10 to version 12 missed a couple of source files. I updated the reference to version 12 and the problems cleared up.
Now the real mystery is: why did it ever work on the old computer?
At this moment I'm working on a MS Access database, and I have difficulties with the library MSCOMCTL.OCX.
The problem is the following: given Windows 7 x64, Microsoft Office 2010 x64 and MSCOMCTL.OCX v6.1.98.34 (which was registered with the help of regsvr32 in the folder SysWOW64), I can't use the TreeView (MsComCtlLib.TreeCtrl.2 class) present in some forms of the database. Every time the code approaches any TreeView's (read, Node's) property, I receive the following message:
"Object doesn't support this property or method" (Error 438)
while in Windows 7 x32 the database works fine.
Trying to understand what's wrong, I discovered that the library Microsoft Windows Common Controls 6.0 (SP6) exists in the list seen in the 'References...' dialog and is checked, but I don't see Microsoft TreeView Control 6.0 in the list of available ActiveX Objects when I'm in the Constructor mode.
Following some solutions found in the Internet, I executed regedit.exe and saw that there are two "folders" in the path HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}, "2.0" and "2.1". Besides, the path to the file MSCOMCTL.OCX is in "2.1", while "2.0" is not also empty - it contains PrimaryInteropAssemblyName property for example, which isn't present in "2.1".
So, what should I do to make TreeViews in my database work? As I've mentioned before, I saw some solutions, but I'm afraid to use them because the computer, where the database is in, is not mine and it's undesirable to make the changes, which can affect security of the system.
The version of MSCOMCTL that is installed by default is not 64-bit compatible. You're unfortunately out of luck. No amount of modifying the registry is going to make a 32-bit only control work in 64-bit office.
However, MS apparently includes a 64-bit compatible version of MSCOMCTL with Office 365 ProPlus installations (source). You can consider buying that, or obtaining it through other means.
We are using C# ZKempkeeper (CZKEMClass) dlls to downloading attendance data from biometric/finger scanning machines.
Some time the code is working fine, but mostly its taking long time and even not giving time out error. This is the line where compiler stuck and never come back
status = zkemkeeper.ReadAllGLogData(iMachineNumber);
I've experienced the same problem before. I had to run it as administrator because the main project is using an external DLL.
try
Actually, from the screen only ZKEMSDK.DLL and "Visual C++ 2003
runtime" is missing but required. The other DLLs above is "normal" to
be missing and will not harm your application's functionality.
Unfortunately since seems Microsoft have removed downloads for C++
runtime before VC2005, you should use the DLL that comes with the
package.
Also, make sure your program compile as "x86" instead of "Any CPU" or
it won't find the DLL on 64-bit systems. (The fact that it depends on
VC++ 2003 runtime implies this must be 32-bit DLL)
https://social.msdn.microsoft.com/Forums/en-US/11fbbd80-cf40-4ecd-8f73-26785cb32383/unable-to-use-zkemkeeperdll-from-64-bit-computer?forum=netfxbcl
I have a Dundas chart being used in a SSRS Report with some custom code in the PostInitilize Event that looks something like this:
foreach(CustomLabel curLabel in chartObj.ChartAreas[0].AxisY.CustomLabels)
{
curLabel.GridTick = GridTick.None;
curLabel.Text = Convert.ToString(Convert.ToInt32(curLabel.Text) - 10);
}
Its takes each axis label and reduces the value by 10.
This works great on my machine, it even works fine on the production server in report viewer. But when this report is run as a subscription, the code fails to run. The report generates just fine but the axis labels are unchanged.
How could this be happening? What is different about running a report as a subscription?
After much searching, I have discovered the solution to this.
The problem is the version of Dundas on my development machine was slightly newer to the one in production (2.2 v 2.1). This causes the code assembly not to be trusted I guess. (but only when running unattended?)
The obvious solution is to upgrade the server, or downgrade my development machine so the version numbers to match. I couldn't touch the installation on the server, and downgrading my own machine would take to long and be annoying. But there is another solution.
Find a machine with the correct version of dundas installed, open the report in Visual Studio, open the code, make a superficial (like adding a blank line, or a comment) then compile the code. This report will now contain the 'correct' assembly. Deploy this to the server, and everything should work.