The Excel provided with the computer does not have 'VBE6EXT. OLB', which makes it impossible to use Visual Basic
I tried to reinstall Excel, but because of the laptop model problem, I could only install it through the files of the computer manufacturer, and their files did not have this function
Related
I'm trying to start object detection project on windows 10, but it is company pc and we don't have license.
so..... I'm just blocked. I google it many time with various keywords such as ["darknet without visual studio"], but there is no good solutions.
please someone tell me how to install darknet without VS.
An amateur programmer has made a nice little program that works through VBA on top of a MS-Access2010 database. We are asked to make an installer for this database+VBA project. The code runs fine on any computer with Office installed, but on computers without Office we get the error above. On computers without office we install the MS-Access2010 Runtime, which is free, in order to be able to open the .accde file at all. But this does not prevent the VBA error.
I did some research on the issue but did not find anything related to this specific scenario. How can this be troubleshooted?
The problem was a version mismatch between the .accde file (sp1) and the installed ms access 2010 runtime (original) After upgrading the runtime to sp1 all was fine.
I am currently supporting a Microsoft Access 2000 line of business application with a number of external dependencies, including Microsoft Word 2007 for mail merges. The application uses a batch script to keep external references up to date by copying and registering (if needed) each DLL on the user's computer, something like the script below:
COPY "\\fileshare\references\fileX.dll" "C:\WINDOWS\system32\fileX.dll"
regsvr32 "C:\WINDOWS\system32\fileX.dll"
Here are the DLL's affected:
comdlg32.ocx (registered)
mscomctl.ocx (registered)
stdole2.tlb
MS09.dll
MSACC9.OLB
msoutl.olb
MSWORD.OLB
VBE6.DLL (registered)
dao360.dll (registered)
msado21.tlb
More often than not the batch script simply replaces a user's DLL with the same version of the same DLL. However, for some reason after this batch script executes and a user tries to open a document in Office 2007, a configuration wizards pops up and steals focus from the document only to require a reboot to finish.
While this isn't really a critical work-stopping issue, it is certainly an annoyance. The obvious guess is that it is one of the Office 2007 DLL's, but I haven't been able to isolate which DLL is the culprit.
Any input is greatly appreciated!
It's my understanding that you should not be distributing the OLB files. They are included in the install of Office, and will already be present on any workstation that has office installed.
You also should not be installing any ADO, DAO, or any other MDAC/WDAC components manually.
For older OS's, you should run an installer (MDAC_TYP.EXE) that installs the entire set of Data Access Components; google for MDAC installer for more info. On newer OS's, WDAC is installed as part of Windows.
Of your list, these are the only files that I would consider safe to distribute:
comdlg32.ocx
mscomctl.ocx
stdole2.tlb (although, this REALLY shouldn't be necessary)
All of the other files are either part of Office, and should already be on the box, or are part of WDAC/MDAC.
If absolutely necessary, you can always install the Access 2000 Runtime. This would allow users that do not have Access 2000 installed to still be able to start your application.
Till now i am using SSIS in Xp Operating System but now i had move to Windows 7.I have
Microsoft Office 2007 installed in my machine.When i am trying to use Excel Source in Windows7
,its is showing Error that 64 bit cannot support Excel Files.
Please tell me what is the exact problem may be & how to get rid of that...?
You need to run your package in 32-bit mode. Here is a usefull link.
Using an arbitrary Windows machine (2000/XP or later), I can
install Eclipse CDT to a USB drive
move that USB drive onto a different
Windows machine--one that does not
have any form of Eclipse software
already installed, and potentially a different version of Windows (but 2000/XP or later)
use Eclipse to develop application-level C/C++ programs on that second machine (and that includes using the debugger), running directly from the USB drive without copying anything to C:.
I can do all this without having Administrator privileges on either machine.
I can do the same with NetBeans, and with several other IDEs that support C/C++ development.
Is it possible to do this with any version of Visual Studio Express?
If not, can you explain the technical reason(s) this doesn't work?
Eclipse is apparently designed to be what Microsoft calls an XCOPY deployment...meaning that it doesn't require any special entries in the Windows Registry (or any other "installation identity" on the target machine) in order to work properly.
Visual Studio is most decidedly not designed like this. It makes extensive modifications to the registry during installation, and those entries (and any other resources like special folder locations) will be missing on any other computer.
So you might be able to install Visual Studio on a thumb drive, but some artifacts of the installation will be put on the C: drive, and you will only be able to use the thumb drive with that machine.
Maybe you could install VS Express in a VM running from the USB drive using Portable VirtualBox or VMPlayer. Not the best performance but its usable for not too big projects or learning.
It can definitely be done! I've seen a technician with a copy of it on a USB stick. the only visible flaw was that when you run on a different PC it requires you to enter the license. I could not see any other problems (speed/debugger etc. it all worked on his copy).
check this out:
http://technet.microsoft.com/en-us/appvirtualization/dd334515.aspx
I believe the virtualized package I saw was made by this means:
http://spoon.net/Studio/
Unfortunately it would be matter of experimenting with it...
No VM or extra software was needed!