I just started working with the Visual Studio 2010 Premium database project. I must say it does indeed rock. One thing I can't figure out is how to avoid the SQL04151 warning
Procedure: [dbo].[MyProc] has an
unresolved reference to object
[MyDatabase].[dbo].[MyItem].
Did I miss a simple step somewhere? All I can find online involves tempdb.
I need to substitute [MyDatabase].[dbo].[MyTable] with [$(DatabaseName)].[dbo].[MyTable]. This cleared up the warnings.
Thanks for your help.
In your [dbo].[MyProc] procedure you reference [MyDatabase].[dbo].[MyItem] which is probably not part of your DB project. Even though the object exists in the DB, it is not known to Visual Studio during compilation and thus yields an error.
Normally you should have the entire DB-schema in the DB-project. Otherwise I think there is something called "partial DB projects" that you can look into.
MS has acknowledged this as a bug they are working on:
https://connect.microsoft.com/VisualStudio/feedback/details/543657/4151-unresolved-reference-warning-for-tempdb
Check you have set Build Action to Build on Properties pane for the specified object..
Related
I couldn't solve this problem after linqConnect For Mysql generated entity of models for me. I thought devart is good software, without testing trial period, I purchased their license, but now I am facing this issue, I couldn't even get it working. please help
enter image description here
The the piece of code highlighted is "System.String.Empty", nothing is wrong here. A similar problem is discussed, for example, at Visual Studio 2015: Intellisense errors but solution compiles. Have you tried to build a project ignoring these fantom errors? Most likely, the build will succeed in this case. To avoid displaying such misleading "errors", choose "Build Only" droplist value (instead of "Build + IntelliSense") in the Error List window from your screenshot.
I want to run Nuint in Visual, so I set
<StartAction>Program</StartAction>
<StartProgram>$(NUNIT_PATH)\nunit.exe</StartProgram>
<StartArguments>Test.dll</StartArguments>
<StartWorkingDirectory>Test\bin\Debug</StartWorkingDirectory>
in my csproj file. But it stll does not work.
Those entries look correct for the project file. The most likely cause of the problem is that $(NUNIT_PATH) isn't properly set and hence gets evaluated to nothing. This would cause Visual Studio to look for nunit.exe in the Test\bin\Debug directory.
To test this try hard coding the full path to the nunit.exe binary into the file.
<StartProgram>C:\the\path\nunit.exe</StartProgram>
If this works then the NUNIT_PATH value isn't properly set.
Unfortunately the Express editions don't support the StartAction mechanism. See MSDN How to: Change the Start Action for Application Debugging.
I'm looking for alternatives though ;-)
Update see also SO-a/10572249/717355: Try http://www2.wealth-lab.com/Wiki/kbDebugExpress.ashx step 13 for a suggestion on making MSVC think its debugging your code directly. - Untried.
I am following example by José F. Romaniello on session management with NHibernate. It's a very good article, however I'm struggling with it having very little experience with NHibernate, Windsor and MVC.
I am trying to re-create NHibernateInstaller, however encountering the following error: Component Castle.TypedFactory.DefaultInterfaceFactoryComponentSelector could not be resolved. Make sure you didn't misspell the name, and that component is registered.
In the sample project provided this error does not crop up, even though the installer is identical and Google does not come up with any results (which is very unusual). What causes this and how can it be avoided?
it seems a problem with the TypedFactoryFacility... are you doing this?
kernel.AddFacility<TypedFactoryFacility>();
before running all the installers?
uncomment the following code in Bootstrapper.cs file.
container.AddFacility();
This happened to me when I created my own implementation of ITypedFactoryComponentSelector, but forgot to register the selector itself.
There was no indication this was the actual problem (and the kernel debug information assured me the components can be resolved) - but registering it fixed the issue.
Hope this helps someone :-)
I have a missing reference listed in my References list (in the VBA Code view). It's a reference to an OCX for a product that we no longer use.
I'm fine with removing(unchecking) the reference, but I'm wondering if that is going to come back to bite me.
Is there a way to find out in which forms/reports it might have been used?
Is removing it and then doing a compile of the MDB sufficient?
I believe if you are using Option Strict, then the compile should catch any issues where you have referenced an object that no longer exists
The compile might not catch it if it's using late binding, but usually it'll catch it in the compile. You can also do some testing by running the recompiled MDB.
If the product is a control, then Access doesn't (by default) let you look at the "source" like that.
Otherwise I would do a search in the VBA code to see where it is created.
eg:
Dim p as New Old_Product
Then do a search for Old_Product across the project.
Depending on how mission critical your application is, I would remove it and see what happens.
I'm assuming that you have decommissioned the old product?
In my experience, Access Applications aren't mission critical. If they go down for an hour (while you try and fix the old reference) it isn't the end of the world.
I have a Access ADP Project that has been a continus project for the last 6 years, so it has hundreds of forms and thosands line of VBA code. After a recent update it not wont compile to create the ADE file. It tells me one of the text boxes does not exist but it does. I deleted the for and re imported it from a working backup and still the same error. I have tryed Importing the whole project into a new ADP file and still wont compile, tryed compact and repair and also /decompile
Does anyone no of any tricks or software package to help fix this problem?
I don't work with ADPs, but in MDBs, there are differences between these two syntaxes for referring to controls on a form:
Me.MyControl
Me!MyControl
The first causes Access to create a hidden property that returns the control. The result of this is compile-time checking of references to controls.
The second uses the default collection of the current form and does not provide compile-time checking.
I assume that VBA works the same in ADPs as in MDBs, so why not try converting the offending control references to bang instead of dot? This would eliminate the compile-time checking and might allow the project to compile without having to reconstruct it laboriously.
If that works, I think I would then try deleting the control (to removed the hidden property definition) and add the control back with a new name and then compact (I don't know if ADPs can be decompiled, but if they can, it should be decompiled as well). Theoretically, this should remove the problematic hidden property definition permanently and if that's the cause of the problem, you should be able to revert to the dot operator and get compile-time checking back.
For what it's worth, I've seen too many corruption problems with the dot operator and always use the bang in all my projects. I'm OK with not having compile-time checking of control references.
And, oh, BTW, with the bang you lose automatic Intellisense (which in some cases is a blessing as Intellisense can get in your way in some contexts), but you can invoke a different Intellisense list with CTRL-SPACE. This list is not limited to the control type, but once you start typing, you get the usual autocomplete that jumps you to the appropriate location in the list.
Sometimes it helps to start a new, empty project and then import all forms/reports/modules from the old one.
If birger's approach doesn't do the trick, consider saving each module using the SaveAsText method. Then, as birger suggested, import, but ONLY the forms, and tables. Then, recreate the modules, using the LoadFromText method.
Sometimes, I found out that I need to manual click Debug -> Compile before making ADE files.
This following steps may help for unable-compile ADP file:
Debug -> Compile
Compact/Repair
then make ADE