The IT Manager

If you have ever tried to setup crontab in Cygwin, you might also have struggled to schedule scripts that reside or read/write data on shared network drives.

When you run an interactive bash shell in Cygwin, by default, your shared network drives are mounted in /cygdrive. So, for example, drive S: in Windows is available as /cygdrive/S in bash.

The trouble is, even if you configure the cron service to run as a specific user, it will not have automatic access to these /cygdrive mount points. The service can see local disks, but not network disks.

To get around this, you have to create a new mount point that mounts the Windows share name directly, not the mounted drive letter. The command to do this is as follows (obviously substituting your own share and mount point):

mkdir /mnt
mount "//[server]/[sharename]" /mnt/[whatever]

Don’t try to create a new mount point under /cygdrive… that does not work (by design).

You can then change your crontab entry and/or script to reference the new mount point and everything should work as expected.

View comments.

I have just posted a C# project called SQLServerScripts that will create script files from every object on an MS SQL Server instance.

You can find the project in my Github repository.

SQLServerScripts

Uses Microsoft.SqlServer.Management.Smo to create scripts for all objects in SQL Server. Useful for tracking database changes in GIT or SVN.

Overview

• Requirements
• Description
• Output
• Interface

Requirements

This project uses assemblies from the Microsoft.SqlServer.Management.Smo namespace. You must have SQL Server Management Studio installed.

Description

Will create scripts for every (useful) object on SQL Server (tested on SQL2008R2).

This includes:

• Logins
• SQLAgent Jobs
• For each (non-system Database):
  • CREATE DATABASE scripts
  • Users
  • Schemas
  • Database Roles
  • Application Roles
  • Tables - including:
    • Indexes
    • Triggers
    • Grant/Revoke statements
  • Views
  • Stored Procedures
  • Functions
  • Synonyms
  • User-Defined Types
  • User-Defined Data Types
  • User-Defined Table Types

Output

From the working folder, it will create the following folder structure containing individual scripts for each SQL Server Object:

• {SERVERNAME}
  • Databases
    • {DBNAME1} - Root folder contains the CREATE DATABASE Script
      • Functions
      • Procs
      • Roles - Application
      • Roles - Database
      • Schemas
      • Synonyms
      • Tables
      • Types
        • User-Defined Types
        • User-Defined Data Types
        • User-Defined Table Types
      • Users
      • Views
    • {DBNAME2}…
      • …
  • Logins
  • SQLAgent

Things to note:

• System databases are ignored
• System owned objects are ignored
• Bad file name characters are stripped from object names before creating the files
• Login scripts have the random password removed and changed to **CHANGEME** (avoids unnecessary source control commits)
• IMPORTANT - To help track deleted database objects, all *.sql files are deleted from the target folder before creating the new version

Interface

Example usage:

SQLServerScripter srv = new SQLServerScripter();
srv.LogMessage += LogMessage; // Event handler for LogMessages

//
// Setup the connection details
// NB: If you do not set SQLServerScripterConnection.User the connection will use
// ActiveDirectory credentials
//
SQLServerScripterConnection c = new SQLServerScripterConnection();
c.Server = "MYSQLSRV01";

// c.User = "MyUser";
// c.Password = "MyPassword";

//
// List of databases to exclude from scripting
// NB: System databases are automatically excluded
//
List<string> DBExclusions = new List<string> { "DBName1", "DBName2" };

//
// Create the scripts
//
srv.ScriptEverything(c, DBExclusions);

Example LogMessage Event Handler:

static void LogMessage(object sender, SQLServerScripterMessageArgs m)
{
    Console.WriteLine("----");
    Console.WriteLine(String.Format("Server: {0}", m.Server));
    if (m.Database != null)
        Console.WriteLine(String.Format("Database: {0}", m.Database));

    Console.WriteLine(String.Format("Object: {0}.{1}", m.ObjectType, m.ObjectName));
    Console.WriteLine(String.Format("Output File: {0}", m.Path));
}

View comments.

Looking at the Scottish Independence polling data from 29/01/2012 to 7/8/2014, it is difficult to see how the Yes camp can swing a victory in the Scottish Independence vote. If you look at a 5 point moving average of all polls, you will see that whilst there has indeed been a recent upswing for “Yes”, there has been an even bigger upswing for “No”.

Averaging out the poll data also shows that whilst individual polls might have the Yes camp pushing the low 40s, the trend has never peaked over 40%.

If you take a 10 poll average, the recent trend is pretty much flat for “Yes” and broadly rising for “No”.

By my estimation, the “Yes” camp will need to swing well over 80% of the “Don’t Knows” just to get a marginal victory. That is not enough. To get a decisive win, they will have to convince a significant chunk of “No”voters to change their mind. That is a pretty tall order this close to the election.

Source: http://ukpollingreport.co.uk/scottish-independence-referendum

View comments.