Monday, 9 July 2012
The only way I could show the DB was to add a connection to a database file. To do this I had to:-
1. Right-click the Data Connections node in Server Explorer and choose Add Connection...
2. Make sure the Data Source field was set to SQL Server Client as shown in this pic.:
3. Then in Server name field type in the name of the new SQL Server Express 2012 instance. In the pic. above, the name of my server is SLIQSQL but for a default installation of SQL Server Express, the server name is likely to be SQLEXPRESS (I just chose a different name during the installation process).
4. Then press the Test Connection button. If all is well you should get a Connection Succeeded message.
5. Finally, choose the database you want to add in the Select or enter a database name field and press OK to close the dialog.
The chosen database should now show in the Server Explorer.
To find out where your database files are stored do the following:-
1. Open SQL Server Management Studio
2. Right click the server name in the Object Explorer pane on the left and choose Properties.
3. In the Properties dialog, choose Database Settings in the Select a Page pane on the left.
The database file locations are then shown on the right.
Saturday, 30 June 2012
VistaDB however does have a few drawbacks that make it unsuitable for larger, multi-user applications which means I'm now looking at using SQL Server Express in some new applications. VistaDB will still be a part of some of my future apps but not part of apps where I want to offer true multi-user capability.
In my experience, the key drawbacks of VistaDB for multi-user apps are:-
1. The lack of a client/ server model. Instead, each VistaDB client directly access the database file and Windows itself manages file locks and such. The result is that when 2 or more users try to access a database file simultaneously access times go through the roof and the app crawls along.
2. VistaDB's lack of paging support, e.g. something like MySQL's LIMIT, OFFSET commands, means that it is hard to avoid reading whole SQL tables of data from the DB to present in lists. Reading large amounts of data from a shared file can compound the Windows shared file performance drop from point 1.
3. In a multi-user app with concurrent access, SQL transactions are essential to ensure consistent updates across tables. Unfortunately, VistaDB transactions are extremely slow causing application performance to drop.
The points above aren't complaints about VistaDB - multi-user apps aren't what VistaDB is intended for. My only disappointment with VistaDB is that it's so good, I just wish there was a simple, easily deployable, client/ server version.
As I gain more experience with SQL Server Express, I'll try and list more pros and cons. One good tool I've found so far for use with SQL Server is OpenDBDiff. This is a free, open-source tool for comparing schemas of two different SQL Server databases and generating SQL scripts to make the schemas match. I can see this tool being essential to ease field upgrades of SQL Server DBs. With VistaDB today, I generate schema update code by hand, so it's a nice, early bonus to find an automatic way of doing this for SQL Server.
Saturday, 23 June 2012
SliQ Article Submitter lets you submit as many articles as you like to as many directories as you can find. Although the package comes with a small list of article directories you can easily add your own. The software supports Wordpress, Article Dashboard, MS and Setup amongst other scripts.
To find out more about SliQ Article Submitter, check out the article submitter info at http://www.sliqsubmitter.com.
Wednesday, 11 November 2009
I'm showing my age here but in the past I've always used Windiff (in my Visual C++ 6 days). Windiff used to let me find out what the differences were between files. I could then merge file contents using a text editor. This process works but it was sometimes difficult to get files to match exactly as there were often extra spaces of line breaks.
Windiff disappeared from Visual Studio 2005 so more recently I've even restored to the old DOS FC command. I did have a quick play with Visual SourceSafe but the solution wasn't really flexible enough - often I want to compare and merge files without locking something down in a configuration management system.
However, I recently came across a package called Beyond Compare from Scooter Software. This package is absolutely fantastic and is now my second favourite software tool (after Visual Studio).
Firstly it remembers folders you've compared in the past. This means you can do a new comparison and merge more easily the second time.
Secondly it lets you move updates from one file to another with a single mouse-click and shows you the results. Any extra/ missing whitespace differences are easily ignored. This makes merging versions take minutes rather than hours.
Thirdly, the software tool itself presents a trustworthy user interface. As you're doing a compare and merge with Beyond Compare, you can refresh the file comparison on the fly and check that things are absolutely identical. Knowing things are the same - bar the differences you want to keep - is vital to ongoing software development.
If merging files and versions of software is something you do regularly I'd recommend going to the Scooter Software site and taking a look at Beyond Compare.
Saturday, 11 July 2009
PHP stores dates and times in Unix or UTC format. This format encodes a time as an integer count of the number of seconds since New Years Day began in 1970 (1st Jan 1970). MySQL on the other hand stores dates and times in string format. All three MySQL date/ time types DATETIME, DATE and TIMESTAMP store data in string format.
MySQL DATETIME and TIMESTAMP columns store in the format:
MySQL DATE columns store in the format:
PHP and MySQL date/ time comparisons
Obviously, this difference in format causes problems when inserting dates and times into MySQL databases and especially when comparing MySQL and PHP dates for example trying to select entries from a table where a date value in the table is older than a PHP date. The easiest way to do this is to use the UNIX_TIMESTAMP MySQL function. For example:
// You could get the date as three integer values from a querystring on the PHP page:
$day = $_GET['day'];
$month = $_GET['month'];
$year = $_GET['year'];
// Then use the day, month and year to construct a PHP time (in seconds since
// 1st Jan 1970 format).
$datetime = strtotime($year.'-'.$month.'-'.$day.' 00:00:00');
// Then find all entries newer than the date given by the querystring arguments.
$sql = "SELECT * FROM MyTable WHERE UNIX_TIMESTAMP(UpdateDate) >= '" . $datetime . "'";
The above SQL query causes MySQL to convert the value of the DATETIME (or DATE or TIMESTAMP) value in the UpdateDate column in the hypothetical table into a PHP format date before doing the compare.
Storing a PHP date/ time value in MySQL
To convert a PHP format date/ time into MySQL's format, the MySQL FROM_UNIXTIME function can be used. For example:
$currenttime = strtotime("now");
$sql = "UPDATE MyTable SET UpdateDate = FROM_UNIXTIME(" . $currenttime . ") WHERE ... ";
Don't use strings for PHP/ MySQL date > or <>
You might find some PHP code examples, trying to use the PHP date() function to format PP dates and times as strings in the correct format to match MySQL values. If you can remember the correct format strings for the conversions this will work as long as you are setting values in rows. For comparisons however, strings aren't any good as the comparison will be an alphabetic/ string comparion and not the required date comparison.
Thursday, 7 May 2009
The main reason I decided not to replace Microsoft Access with SQLite was that I'd got too used to ease with which I could get when using the .Net datatypes seamlessly with Microsoft Access, e.g. I could read and write the .Net Decimal type straight to Access. With SQLite it seemed that I might have to convert to and from strings to preserve accuracy. This wasn't a big showstopper but I'm afraid I like my programming to be as easy as possible.
I'd pretty much resigned myself to using Microsoft Access but then I came across a really neat database system called VistaDB. VistaDB looks (I suspect) like it may have been originally based on SQLite but the great thing about it is that it has the rich data type support you get with Microsoft Access - plus extras like stored procedures - without losing the no hassle deployment of SQLite. I've spent a few hours evaluating VistaDB and so far it looks ace. For my particular application it solves all the downsides of both SQLite and Microsoft Access.
Monday, 6 April 2009
I've had a bit of a play recently with SQLite and ADO.Net to see if I could slot in SQLite instead of MS Access in my desktop application. As yet I haven't made my mind up, but it's been a very interesting exercise. Here's a quick summary of my findings so far.
With my limited experience, SQLite seems to support fewer data types than MS Access. On the whole this isn't a problem apart from two areas - the .Net Decimal type and the .Net DateTime type. In both these cases I think you end up having to encode the data as strings and take care of any localisation issues yourself, e.g. making sure dates stored in France can be read in the UK and vice-versa. I haven't delved into Decimal storage too much but I think strings will need to be used instead of squeezing data into the Double data type and experiencing potential rounding errors.
Complete ADO.Net Support
The SQLite support is pretty comprehensive but misses out in one or two areas like the RowStatusUpdated event handling.
If you open a connection to a non-existent DB, SQLite seems to create an empty database at the specified path. This isn't a big issue but it means that the "DB doesn't exist" error turns into a "Table doesn't exist" error when you try to access a table in the DB.
Note: Since I wrote this post, I've found out that you can use connection strings to alter the default behaviour of creating an empty DB when the target DB can't be found. Read SQLite Connection Strings for more info.
On first impressions, data access with SQLite is very quick and certainly quicker than MS Access. However, if you have to start encoding and decoding data into strings (DateTime for example), I'm not sure that the performance wouldn't start to degrade.
With SQLite there is essentially nothing to install. All you need to do is copy the assembly into your application folder and you are up and running. SQLite wins hands down here.
None for now, except to say that SQLite looks very tempting as an Access replacement especially as it's so easy to deploy. I'll post more info as I gain more experience.
Sunday, 1 March 2009
Tuesday, 13 January 2009
There are a number of reasons for the increase in traffic.
- Being a shareware directory, SoftwareLode naturally builds links over time as authors link either to the homepage or to the details page for their software packages.
- As well as an increasing number of links, better internal linking has also helped. Each software details page now links to up to 10 related programs, i.e. programs with the same keywords. Getting more, relevant links to the program details pages helps pull pages out of the supplemental index.
- Better linking from the homepage into the rest of the site spreads the homepage PR around more efficiently. The homepage now lists top selections in a number of categories. The details pages for the top selections then link to related programs and so improve the rank of lots of the inner pages.
As SoftwareLode was launched only 7 months old, I'm pretty pleased with its performance and hopeful of further increases in traffic in the months ahead.