alter system flush shared_pool; -- flushes the cache
select * from v$sqlarea; -- for baseline
-- execute your code/sql here
select * from v$sqlarea; -- compare to baseline
keywords: sql history, past sql, previous sql statement
If you copy a .net application to a network share and try to run it, you will be default get a unhelpful error message.
"... has encountered a problem and needs to close. We are sorry for the inconvenience."
There are at least 2 ways around this:
1. You can use the .NET Framework configuration tool (Mscorcfg.msc) to change the security policy.
For .net 10, 1.1 see: http://support.microsoft.com/kb/832742
For .net 2.0: This is only installed with the SDK, so you'll likely need to use CasPol.exe below.
The easiest way to modify your security policy is by using the Microsoft .NET Framework Configuration utility from the control panel. You can also run this tool from the command line by running mscorcfg.msc.
1. Expand the Runtime Security Policy folder
2. Expand the Machine policy level
3. Expand the Code Groups folderTo modify the polcy to trust a specific strong name:
1. Right click on All_Code, and select New
2. Create a new code group for your strong name, and hit next
3. Select a strong name membership condition from the drop down box
4. Hit the import button, and select your assembly. The configuration tool will import your public key. If you want to trust everything you sign with this key, leave the name and version boxes unchecked
5. Select the FullTrust permission setTo modify the policy to allow full trust for all Intranet assemblies:
1. Expand the All_Code code group
2. Right click the LocalIntranet_Zone code group, and select properties
3. Switch to the Permission Set tab, and select FullTrust
2. On the clinet pc you can give full trust access to the whole share which allows running any .net apps frim that share (or just an individual file if you wish) as follows:
CasPol.exe -m -ag 1.2 -url file://storage/files/* FullTrust
See: http://blogs.gotdotnet.com/shawnfa/archive/2004/12/30/344554.aspx
Although there is a relative Reference HintPath in the .csproj file, when you move a solution to a different machine, the hint path may not be correct for that machine. An easy way to get around this problem is to just ensure that your needed assembly is in the Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies. Of course this should really only be done when you don't make any changes to the referenced assembly, such as a 3rd party dll.
A good summary: http://blogs.msdn.com/manishagarwal/archive/2005/09/28/474769.aspx
From: http://msdn2.microsoft.com/en-us/library/8y13ka7c(VS.80).aspx
When the project system finds an assembly reference, it resolves the reference by looking in the following locations, in the following order:
1. The project directory. The project directory files appear in Solution Explorer
when Show All Files is not in effect.
2. Directories specified in this dialog box.
3. Directories displaying files in the Add Reference Dialog Box.
4. The project's obj directory. (Any assemblies created as a result of adding a COM
reference to your project are added to the project's obj directory.)
From: http://msdn2.microsoft.com/en-us/library/wkze6zky(VS.80).aspx
To display an assembly in the Add Reference dialog box
* Move or copy the assembly to one of the following locations:
o The current project directory (you can find these assemblies using the Browse tab).
o Other project directories within the same solution (you can find these assemblies using the Projects tab).
o The Public Assemblies folder: Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).
* Set a reference path to the directory containing the assembly using the Reference
Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#,
J#).
* Set a registry key that specifies the location of assemblies to display:
Add one of the following registry keys, where <AssemblyLocation> is the directory of the assemblies that you want to appear in the Add Reference dialog box, for example, C:\MyAssemblies\.
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
THIS WAY HAS WORKED WELL FOR ME:
The easiest way I have found to immediatley shrink the log file is to detach the database, rename the .LDF file then reattach the .MDF file. In SQL Server 2005 you'll need to remove the missing .LDF file from the list before attaching, and one will be created for you.
I DID NOT GET THIS ROUTINE BELOW TO WORK WITH SQL SERVER 2005:
From the April 2001 edition of SQL Server Magazine:
Shrinking Log Files Immediately
You can use the DBCC Shrinkfile statement in SQL Server 7.0 to shrink the size of a specified data file or log file for a related database. But SQL Server professionals often ask me why the DBCC Shrinkfile command doesn't shrink the size of their transaction logs immediately and how to make their transaction logs smaller.
SQL Server 7.0 doesn't immediately shrink log files when you issue the DBCC Shrinkfile command. The DBCC Shrinkfile operation occurs only at checkpoints or transaction log backups. SQL Server segments each physical log file internally into a number of virtual log files (VLFs), which make up the transaction log. SQL Server marks the VLFs as truncateable either after SQL Server has backed them up or at checkpoints. At any given time, you might have VLFs with free or reusable space at the beginning, middle, and end of the log. Only when the VLFs that SQL Server marked as truncateable are at the end of the log file can the DBCC Shrinkfile operation remove the VLFs and shrink the log file. Because SQL Server can shrink a log file only to a virtual-log-file boundary, you can't shrink a log file to a size smaller than the size of a virtual log file—even if you aren't using the log file. (For more information about virtual log files, see SQL Server Books Online—BOL.)
Listing 1 shows a script that shrinks the log file immediately after you stop running the script. The script first marks a shrinkpoint, which tells the DBCC Shrinkfile (or the DBCC Shrinkdatabase) command where to shrink the log file to. The script then forces truncateable VLFs to the end of the log file and issues a BACKUP command to truncate the log. In my experience, you need to run the script for 3 to 4 minutes before stopping it manually.
—Simon Su yqsu@microsoft.com
Listing 1: Script to Shrink a Log File
/* Run "SELECT fileid, name,filename FROM <db_name>..sysfiles" to get
the fileid you want to shrink. */
USE <db_name>
GO
DBCC shrinkfile(<fileid>,notruncate)
DBCC shrinkfile(<fileid>,truncateonly)
CREATE TABLE t1 (char1 char(4000))
GO
DECLARE @i int
SELECT @i = 0
WHILE (1 = 1)
BEGIN
WHILE (@i < 100)
BEGIN
INSERT INTO t1 values ('a')
SELECT @i = @i +1
END
TRUNCATE TABLE t1
backup log <db_name> with truncate_only
END
GO
From microsoft.com:
"Beginning in Exchange 2007 Beta 2 and Outlook 2007 Beta 2, CDO 1.2.1 will no longer be provided as a part of the install of the product. As a result, there is functionality missing that many applications depend upon. CDO 1.2.1 is a package providing access to Outlook-compatible objects through a COM-based API."
You can download Collaboration Data Objects, version 1.2.1 from microsoft here.
Just as a note, CDO was included as an optional accessory starting with Outlook 2000-ish.
EXEC sp_rename 'tablename.oldindexname, tablename.newindexname', 'INDEX'
Don't forget the tablenames.
I'm always forgetting my dsn-less connection string formats.
VB6:
Oracle:
Provider=OraOLEDB.Oracle.1;Data Source=tnsname;User Id=userid;Password=password;
Sql Server:
Provider=sqloledb;Data Source=servername;Initial Catalog=dbname;User Id=userid;Password=password;
.Net
Oracle (OracleClient):
Data Source=tnsname;User ID=userid;Password=password;
Sql Server (SqlClient):
Server=servername;Database=dbname;User ID=userid;Password=password;Trusted_Connection=False
If you want access to the individual files within your complete pc backup, then the built in Complete PC Backup in WIndows Vista isn't for you. You can only restore your complete partition.
A caveat to the above is that I have heard you can mount the above backup file in Microsoft Virtual PC as a harddrive, which in theory would allow access to the individual files however this would require you have Virtual PC installed and I have not tried this.
Acronis True Image 10 is compatible with Windows Vista and allows you to explore the backup files in explorer.
I installed the Windows Vista Ultimate final over the weekend and here are some notes on what I did before doing a fresh install.
Run the Windows Vista Analyser to determine how well your pc can handle Vista. Don't expect it to catch everything, it will not.
Do a full bootdrive backup. No seriously, do it! I recommend Acronis True Image.
Decrypt all files encrypted by the os (or if you have the know how, export your certificates, etc.) Your encrypted files will not be readable in the new OS since the user's SID will be different. (If you are upgrading and not doing a fresh install, you probably don't need to worry about this.) If you backed up your encrypted files with Windows XP/95's backup tool before you decrypted them you will still not be able to read them as the backup actually backs them up as encrypted files.
During the install, I chose to format the boot drive since I had done a full backup. I have never fully trusted Windows upgrades, so I always do a full install.