If you specify . ./file.ksh, it's like running the contents of that file in your current shell. It's a bit smarter than this, but think of it running:
while read line; do "$line"; done <file.ksh
Since it's run in the current shell, any variables it sets, for example, are available in your current shell.

If you run sh file.ksh, you're running "sh" (which may be linked to ksh or bash or whatever) with file.ksh as input. In many cases, "sh" is not the same as "ksh", so different syntax applies. It's run in a child process, though, so variables you set are not available later in your current shell.

If you run ./file.ksh, the first 4 bytes of the file (the file "magic") are read, determined to be a script, and the executable, if available, identified after the shbang is run, feeding the file as input. Also run in a child, so no variables are available after control is passed back to your current login shell.

In basic cases, they may all lead to successful execution of the script - it depends on the script. They're all different ways of executing, though, and follow slightly different rules for syntax - this is a hand-wavy explanation, of course, but I think it covers the gist of what you're asking.

Here's a fun example:

Code:

$ cat file.cat
#! /bin/cat

$

So, my file called "file.cat" contains the above.

Code:

$ . ./file.cat
$

My shell (bash) sources the file, and finds only a line beginning with "#", which is a comment, and a blank line. Nothing to do here - no output.

Code:

$ sh ./file.cat
$

I ran "sh" (although on my system, it is still bash, it follows slightly different behavior when called as "sh") with the file as input, still only finds a comment and blank line - nothing to do here.

Code:

$ ./file.cat
#! /bin/cat

$

This is kind of cool, actually. When invoked, the file is determined to be executable, and a script. Since the interpreter after the shbang is /bin/cat, what is essentially run is /bin/cat ./file.cat

This also demonstrates a quine.