i just want to ask about Visual studio doesn't detect my microsoft.ace.oledb.12.0..
last month i write a code to import from excel into database using VB.NET and it worked..
but after a month i open back my coding and try the system but it said that "microsoft.ace.oledb.12.0 provider is not registered" even though i already install microsoft access database engine 2010 before..
i never change a little bit of my coding..i just left it but now it doesn't work like before
is there any particular update or something that make it doesn't work??
thank you
Try changing your target cpu in your project properties. go to solution explorer<properties<Compile uncheck the prefer 32-bit or change to x64. It works for me, if it doesn`t work try searching a bit more iirc that question is already answered but i cant remember if it is in stackoverflow or other website, which has many suggestions
The Access engine can be installed as either 32-bit or 64-bit. As the other answer notes, it is important to make sure that your application matches the bitness of Access. You can check on installed OleDB providers by checking the Windows registry; you would need to search on all of the keys in HKCR/CLSID (under Wow6432Node for 32-bit), looking for entries with a value named OLEDB_SERVICES. Keys with this value will have the provider name as the default value. This (obviously) isn't practical to do manually, but it should be fairly straightforward to do programmatically.
Related
I have an Excel file that contains VBA code and user forms.
One machine has been migrated to Windows 10. The Excel major version hasn't changed though (16). One of the forms lost almost all the controls on it and the user is getting
Compile error: Method or data member not found
at the line Me.cmbWeek.ListCount.
It looks as if this control is not existent in the file on that machine. I wouldn't say it is Windows10 incompatibility as some other machines migrated to Windows 10 flawlessly.
How can I debug what's wrong? The file has worked for years on several machines including the machine of this user (until on Win10). Checked references and there's nothing missing.
The form on user's machine (broken).
The form on on all other users' machines (proper).
I cross-posted to other forums:
excelforum.com
mrexcel.com
ozgrid.com
We managed to trace the problem to the DTPicker2 control on the form. It is part of MSCOMCT2.OCX library. It is present on user's machine, the same as on mine. That machine is version SP4 of the file whereas all other machines have SP6.
I can see that Excel reference points to some other destination than C:\Windows\SYSWOW64 - it points to other app's install path. Probably other app changed something in the registry.
When trying to uncheck the SP4 reference and load SP6 reference I get error
"Can't change references, in use".
Reinstalling office and registering MSCOMCT2.OCX did not help. As it's only two controls causing the issue - or so it seems - I'm now into replacing them with other date picker controls if there are any. If not, I might even use plain textboxes, though it wouldn't be very good solution. Are there any other controls that could handle calendar?
Do check if the region settings on the PC with Win10 the same as on the older PC's.
Changes in date formats, dots vs comma's, etc. can hugely impact VBA's ability to tinker company processes together.
I have just run into an issue with my app name already being reserved in the Store. I have chosen another similar app name to reserve, but now I need to change my actual application solution name to match. I want to be sure that the name I chose in the store matches the name of the solution that a user will see on his or her device once downloaded and installed. How can I properly accomplish this? My previous experience has always resulted in many errors by simply changing the solution name within the solution explorer. Please help.
I am working SDL TRIDION 2011 SP1 version. Suddenly I am unable to see the Trdion site in Internet Information Services(IIS) Manager. Please tell me the procedure how to get it back again.
Remove Tridion Completely (uninstall), then run the installer again.
You won't loose any data (it's all in the database), and you're likely to get your server up and running way faster than trying to fix by hand.
As #bart suggested, your best option to get the web application back (assuming it really has gone), is to run the repair option with the installer. There are a lot of folder specific settings which would be very hard to recreate manually.
I have recently upgraded to the new Azure SDK (September 2011 v 1.5).
Ever since I have not been able to start the compute emulator. Consequently I can't debug the services on my local machine.
I have seen a suggestion that the problem lies with the fact that my user account has a space in it, so I renamed my account but that didn't make any difference. It may be that the problem is that my user profile path has a space in it. Changing the account name has no effect no the profile path.
On the msdn forums it was suggested that I remove *:808 binding in IIS Manager for Default Website. See MSDN Forums
Anyone have any other ideas?
Another option:
So, given the "rename your user account/regedit doesn't work for you, you may want to look at this MSDN article, which suggests you can just set an environment variable and run the emulator without mucking with the registry... not sure if setting the environment variable globally would let you run automatically within VS.NET without manually starting up the emulator the first time, but it is certainly easier.
Yes, the space(s) in your profile path are the issue, and this appears to be a regression for a bug that was found in a previous version of the emulator (the only reason I even thought to try logging in with a different account in the first place). I was literally just putting together a quick blog post here describing the same issue. You'll need to do some registry editing to fix all the references to your old profile path if you want to fix it, or just create a new user if you can deal with re-installing software (I love the Web Platform Installer, but I found out during this exercise that it doesn't do a good job installing for "all users").
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.