What is the VistaDBContext object?

Think of the VistaDBContext as your host container for the CLRProc.  It is the part of the engine that is kept per connection and allows the hosted CLRProc to communicate to the Engine through a Pipe object.  This is very similar to how it works in SQL Server.

Why can't you communicate direct to the engine?

The VistaDB Engine is not in the same namespace as the procedure.  The procedure has to be loaded and then JIT'd in order to run from within the database.  But that does not mean the engine can trust the assembly entirely.  It keeps itself isolated from the stored proc as much as it can.

What about threading withing a CLR Proc?

If you create a thread within a CLRProc is does not have any VistaDBContext associated with it.  This means you cannot call back to the engine from the worker thread.  You might do this if you are performing some very long process and only want to update the database that the process completed (could do this with a new Process as well). 

The only way to communicate back to the database in this case would be as a totally new client (Open a new VistaDBConnection to the database). 

This comes with all the normal drawbacks and benefits.  You get to use the ConnectionPool.  But if you have the database open in Exclusive mode you will not be able to access it from the second thread's connection.

As an example let's say you had a CLRProc that FTP'd a file to another server and was going to take a while.  You decide to spin up a thread to complete this task.  The new thread then would have to create a new VistaDBConnection and perform an update to the table telling it the transfer completed.

What happens when you open a connection to a database from within a CLR Proc?

If you open a new Connection it is just like a separate application connecting to the database.  Unless you use the VistaDBContext your clr procedure may as well be running within another application.  There is no other communication channel other than the context pipes between the engine and hosted procedures.  This is important to understanding why certain things cannot be performed within a hosted clr procedure. 

What is the difference between a method tagged with FillRow?

The difference is in how it may be called from within your SQL code.  Do you wish to call it like a UDF function?  Then FillRow is not required.  You may call the function using EXEC Functionname(someparam), or SET @VARIABLE = Functionname(someparam).  But you cannot select * from Functionname(someparam) unless you have a way to enumerate over the rows.  This is the purpose of the FillRow attribute - it tells the VistaDB Engine what function must be called to assign the values to each row in the output.

Context can be a tricky subject because it is not one with much information (even from the SQL Server folks).  There is also a DDA ability to communicate through their own DDA Channel Pipe which was moddled after the SQL Channel Pipe.

I continue to be amazed at the great things you can do with VistaDB, and just how subtle from of the examples truely are.  The current CLRProcs demo is actually demonstrating around 15 topics that are not always apparent.  We will be breaking it up into multiple applications to demo key concepts better and hopefully remove some of the confusion around CLRProcs.  They are quite powerful and easy to code too.