I have a client who needs to ensure that the system cannot be compromised from a 'disgruntled employee' - ie taking a copy of the 'front end' (the data is not a problem, it is the actual workings and coding that needs to be secured.
The current system is too large to make an ACCDE file (40,000kb).
I have tried reducing, compacting etc. No Joy
I also tried creating a brand new copy and re-importing all modules and objects. No Joy
I then tried creating a blank database with only 1 form and some code to undertake the importing of the objects. The code worked fine.
The file with just the form and code worked in creating the ACCDE file but the code then failed to run as it is 'transferring objects' and ACCDE files will not allow that.
Are there any alternatives to solve the original problem?
Thank you
When you are creating ACCDE file, be sure to check if project is compilable:
After this, you'll get errors, that prevents you to create ACCDE file.
Other point is that if you are using other files as source libraries (through References), then you should compile them also. ACCDE would accept only ACCDE files as Access files as library sources.
Anyway, just try first solution, it should help you as I think. Because 40 Mb - not a size for ACCDE. Only limitations I know: not more than 1000 objects in database, not more 2 Gb database size for 32 bit Access.
Van Ng - Thank you.
I missed the obvious - after checking if the project using 'Compile Project...' I found some old, redundant code that I had left in with a variable that had not been declared.
I have fixed that and it compiled.
Problem Solved - many thanks.
Related
i have a problem regarding the process of saving a bunch of pdfs (exported from WordDocuments).
The runtime of my program just behaves a bit weird and thats why i am asking.
So I want to save the files on a global drive.
In my program i create a folder (in that drive where) i put all the pdfs.
Somehow if i do this operation for the first time it is really slow.
But if I do this operation ( for the same fodler a second time) it is somehow really fast. (after I deleted the "old" pdfs, or the old pdfs where overwritten)
I am a bit frustrated and I cannot explain why that is
Could somebody help pls
Would be very happy for an answer
Greetings
Jonas
Using this simple code
doc.ExportAsFixedFormat wholefile, ExportFormat:=wdExportFormatPDF
There are multiple reasons why the ExportAsFixedFormat method can be slow. But I would start from dealing with local files only. Then I'd play with arguments specifying the document quality and exported format. It makes sense to play with other parameters left in your code sample to its default values.
In a huge SSDT database solution with lots of projects and references, I'm adding a reference from my project to system databases(master, msdb), it works well, and the build is successful.
And after some time I start receiving errors about incorrect reference. I go to the references section and see this: https://pasteboard.co/JqzDSDh.png
I tried removing the second reference and the errors were gone but then this issue comes back and I see two identical references again.
Thank you!
Most probably something is wrong with your project.sqlproj file. Try to search master.dacpac keyword there and make sure that there is no multiple entries. Make sure that dacpac path is not fully hardcoded, but uses $(DacPacRootPath) variable there.
This is an example how the reference should look like (make sure that you have the right SQL version defined in the path. Mine one is 140 here).
<ArtifactReference Include="$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\master.dacpac">
<HintPath>$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\master.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
<DatabaseVariableLiteralValue>master</DatabaseVariableLiteralValue>
</ArtifactReference>
If that wouldn't help, try to run "Clean Solution", then delete all *.jfm files and *.dbmdl files, bin and obj folders and re-build the project.
Issue
I'm having some really odd compile issues using Visual Studio 2013 and it's really disrupting my teams workflow.
The issue is hard to explain but I will provide screen shots and code snippets to help people understand the problems we are facing.
We have a project that we recently moved to VisualStudio 2013 from 2010 and upgraded it to .Net 4.5, the project is a ASP.net Web Forms project.
The code compiles and runs but oddly when I change any of the class files sometimes even just adding a comment 'Test Comment it fails to compile.
The errors shown in the error window are all wierd and the IntelliSense shows errors in the wrong place, some of the errors are even completly off. An example is _To is not defined in the line Dim _Town as String or in the same line 'ring' is not defined which is oviously part of the word String
ScreenShots
Here are some of the errors after I added the failing code at line 44 and then commented it out and re-compiled
What I've tried
I've tried to change the files line endings and make sure they are all Windows CR+LF, I've tried snooping in the build output nothing I can really see to help me.
I even brung the solution down from source control on another machine to test and it had the same issue. It didn't actually compile properly at all on the new machine but I don't know yet if these two issues are related.
I had the same issue as yours, and also the same scenario (I had upgraded a very old VB.NET project to a 2013 project).
The issue seem to be related to file encoding. I don't know the exact cause, but it might be having multiple files with different encoding (In my case, some files were ANSI, other files were UTF-8 w/ BOM).
If you aren't sure about having files with different encoding, open them in Notepad++. You should see the file encoding in the bottom-right corner.
At first, I have convert the offending file to ANSI to see if this will resolve the problem. I opened the offending file in Notepad++, selected Encoding-Convert to ANSI, Saved, Encoding->Encode In UTF-8 without BOM, Saved and Reloaded the file in VS. Now the project compile successfully.
However, I didn't want to do this every time I changed the file, (since VS convert it back to UTF8), therefore I copied all the old files (In my case they were 4 files only) to a temporary directory, deleted the files from VS and created new files with the same name, and I copy/pasted the content into each file. Now all my files are in UTF8, and I am no longer having this issue.
The solution is to either convert your files to ANSI as UTF8, or convert them to UTF8 (This seems to be the default encoding for newly created files in Visual Studio, so I suggest converting them to UTF8)
If you have a lot of files I think you can try to convert them to UTF8 using Notepad++.
Regards.
I've got a question about building a deployment script using SSDT.
Could anyone tell me if it's possible to build a deployment script using SQLPackage.exe where the source file is NOT a dacpac file, but uses the .sql files instead?
To give some background, I've created a project in Visual Studio 2012 for my database schema. This works great, and SSDT builds the folder structure without a problem (functions, stored procedures etc which contain all the .sql files).
Here's the problem - the database in question is from a legacy system, and is riddled with errors. Most of these errors we don't care about anymore and it's not practical or safe to fix them all, so for years we've basically ignored them. However it means we can't build the project and therefore can't generate the dacpac file. Now this doesn't prevent us from doing the schema compare and syncing the database with the file system (a local mercurial repository). However it does seemingly prevent us from building a deployment script.
What I'm looking for is a way of building the deployment script using SQLPackage.exe without having to generate the dacpac file. I need to use the .sql files in the file system instead. Visual Studio will produce a script of the differences without building the dacpac, so this makes me think it must be possible to do it using SQLPackage.exe using one of the parameters.
Here's an example of SQLPackage.exe which I'd like to adapt to use the .sql files instead of the dacpac:
sqlpackage.exe /Action:Script /SourceFile:"E:\SourceControl\Project\Database
\test_SSDTProject\bin\Debug\test_SSDTProject.dacpac" /TargetConnectionString:"Data
Source=local;Initial Catalog=TestDB;User ID=abc;Password=abc" /OutputPath:"C:
\temp\hbupdate.sql" /OverwriteFiles:true /p:IgnoreExtendedProperties=True
/p:IgnorePermissions=True /p:IgnoreRoleMembership=True /p:DropObjectsNotInSource=True
This works fine because it uses the dacpac file. However I need to point it at the folder structure where the .sql files are instead.
Any help would be great.
As has been suggested in comments, I think that biting the bullet and fixing the errors is the way ahead. You say
it's not practical or safe to fix them all,
but I think you should give this a bit more thought. I have recently been in a similar situation to you, and the key to emerging from it is to realise that the operational risk associated with dropping procedures and functions that will throw an exception as soon as they are called is zero.
Note that this does not apply if the reason these objects won't build is that they contain cross-database or cross-server references that are present in production but not in your project; this is a separate problem altogether, but also a solvable one.
Nor am I in favour of "exclude from build" as an alternative to "delete"; a while ago I saw a project where this technique had been deployed extensively; it makes it harder to see what does what from the source files and I am now of the opinion that "Build Action=None" is simply "commenting out the bits that don't work" for the Snapchat generation.
The key to all of this, of course, is source control. This addresses the residual risk that one day you might indeed want to implement a working version of one of your currently non-working procedures, using the non-working code as a starting point. It also obviates the need to keep stuff hanging around in the solution using Build Action=None, as one can simply summon an earlier revision of the code that contained the offending objects.
If my experience is any guide, 60 build errors is nothing; these could easily be caused by references to three or four objects that no longer exists, and can be consigned to the dustbin of source control with some enthusiastic use of the "Delete" key.
Do you have a copy of SQL Compare at your disposal? If not, it might be worth downloading the trial to see if it will work in your scenario.
Here are the available switches:
http://documentation.red-gate.com/display/SC10/Switches+used+in+the+command+line
At the very least you'll need to specify the following:
/scripts1:
/server2:
/database2:
/ScriptFile:
Ì have had this problem in a number of projects and I have almost given up. I am sure there is a solution though. When I insert a Flash object in a VB.Net Windows Forms application, it works fine for a little while and then I see this error in the Design Screen. I am using Visual Studio 2010
Could not load file or assembly 'Interop.ShockwaveFlashObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I have read several descriptions of why this happens, and apparently it has something to do with strong naming (or lack thereof), but have not found a solution yet. I used Add Reference->COM->Shockwave Flash (C:\Windows\SysWOW64\Macromed\Flash\Flash32_11_2_202_235.ocx) If I ignore the error it appears to work fine, but I don't want my users to have a problem.
I know I can use a browser control and play the Flash in that, but for reasons I won't get into, I have to use a Flash control. Any ideas would help.
Okay. I can't promise this to work for you, but it worked for me.
First, you have to locate a file on your computer titled AxImp.exe. You have to run it from the command prompt. This file is located (for me at least) here:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\x64
Once you do find and run it, you have to point it to the correct Flash.ocx file you're using, like so:
AxImp.exe <path>\Flash.ocx
Once you've done that you should end up with 2 DLL files in the same directory as the .ocx file. One called AxShockwaveFlashObjects.dll and another called ShockwaveFlashObjects.dll.
You don't care about ShockwaveFlashObjects.dll, just AxShockwaveFlashObjects.dll.
Grab that file and the Flash*.ocx file and paste them into the project directory.
Then include them into your references. This should open up two new references, AxShockwaveObjects and ShockwaveObjects.
Make sure you're Using both of them.
After this, you have to register the Flash*.ocx using RegSvr32 from your command prompt (make sure to run CMD in admin mode). That is done like so:
C:\RegSvr32 <path>\Flash.ocx
This worked for me. I was having the exact same problem (which is what led me here). It could be a half backed hack workaround but for now, that's how it worked for me.
Let me know if it works for you or not.
Hope it goes well for you.
I know this is an old post but I had this issue yesterday and the solution, at least in my case, was very simple. All I had to do was to change the Platform and Platform Target to x86 (Build tab of project property).