xsharp.eu

Hi X# guys,

I am currently working with a Virtual Machine which is running X# with all the related apps like Visual Studio, SQL Server and Management Studio.

I am making available some 'ClickStart' eNotes I mad a while back on VM's for a previous 'DevShare' event.

Here is the link to my OneDrive folder :-

https://1drv.ms/u/s!AiCBl-gBWjY9g_dRSaFZqZdBI1Aojg

At the moment I am just starting to add a further Appendix section to hold everything that I have done yesterday to get my VM working for X#. In the following image you can see the empty sub-folders (Appendix 'X#') :-
I will let you know when the new version of the CHM is available.

Hope this helps,

Phil.
Wales, UK.

Hi Phil,

according to some Microsoft documentation about virtualization you need at least 2 cores for Windows versions after Windows 7. XP can run with one core, but Windows 7 needs at least two cores.

So this is not an issue of Visual Studio or SQL Server, but of the VM OS. X# (and XIDE) are not ressource hogs, so they may behave a bit better in underpowered environments (during my last flights to New York and back, I have programmed happily witn XIDE/X# on my Windows tablet with only 4 GB of memory, a Core i3 with 1,7 Ghz and a 11" 1366x768 screen).

Wolfgang

This looks great. I will do also some "documentation" with Word. Also, I finished my OS Upgrade and Hyper V install and it looks like VS 2017 (incl. x#) and SQL Server 2016 are running. Finanly, imported your database and now I am ready to go...I am <--so--> am excited!!!

Cheers
Michael

Wolfgang.

I would love to say that this problem is the fault from Microsoft, but that is not the case.
We simply mad an error in our code which causes our background scanner to crash on machines with only oen (virtual) CPU.

Robert

Hi Robert,

thanks for this clarification!

We humans all make errors, and we programmers seem to make more than other people (at least is this the sensation I have during my daily work). But only serious programmers will admit when they make an error.

Wolfgang

Wolfgang, Robert and all,

My findings from the experimentation I have carried out would appear to agree 100% with Robert's statement.

With 1 processor chosen for my VM the C# cade for small test apps compiled and worked, whereas the X# equivalent did not.

Changing the VM settings so that I used 2 processors, seemed to allow the X# code for these test apps to run equally as well as the C# cones.

At the moment I am not too bothered with the setting, as long as I can keep going with my work on integrating SQL use with X# apps in VS 2017 - for Michael and any other interested guys.

Well all should learn from our mistakes, and hopely other can too - hence the need for us all to be open and honest - thanks Robert !

Must shoot, taking daughter to railway station ;-0)

Regards,
Phil.
Wales, UK.

Hi Michael,

I am glad to hear about your success, so far.

Now that you have imported the data file (MDF) I assume it is in 'C:Temp' and that the file / folder is set to full edit facilities etc..

The next step on the way to getting X# up and running with SQL is to attach the chosen database to either Management Studio of the facilities in VS.

Right click the 'Databases' folder as seen below :-
Then navigate to one of the available MDFs - see below :-
Then click OK to get stuff going .. :-
If you have things set up correctly you will now see the new entry under 'Databases' :-
Enough for now, in my next post we will try and access the data by sending a query and listing some results.

Good luck any gut following Michael and his quest.

Cheers,
Phil.
Wales, UK.

Hi Phil,

successfully accomplished.

Cheers,
Michael

Okay SQL guys,

A short post about Attached and Detached databases. This topic is 'small' but not an easy one - I have been fighting it for years, it would seem.

Lets start this 'art form' topic (no rhyme nor reason!?) by looking at the Management Studio end of things.

If we have a SQL server showing in the 'Object Explorer' pane, then before we can access a specific MDF (data base) we have to have it showing in the folder called 'Databases'. The way MDFs get into and out of the 'Databases' folder is by Attaching and Detaching. Sounds easy but some times things seem to get 'locked up' (from time to time) and we have to resort to closing apps and restarting them - messy. I have learned to live with this - but the good news is that from X# code life is not as 'strange' ;-0)

Previously, we saw in an image how we Attach by right clicking the 'Databases' folder, but to 'Detach' we need to right click the required Database entry itself. See below :-
If all goes well (to plan) then the entry will disappear from the Object Explorer list - but then you may also need to refresh this list, and it may behave slightly differently in your version of Management Studio or Visual Studio - I did say ... "an art form!".

So Tasks and Detach ... do the trick, hopefully, of removing the MDF from the list.

Now then, going further on this rather tricky topic, if we have an MDF attached in the Object Explorer pane in MS or VS we may get an issue in our X# coded application when we run it - but apparently only the first time we try.

Sometimes I need to Detach an MDF and this frees the .NET app to work okay, but more strangely the re-attached MDF seems then not to bother our code from running smoothly. As I said its a bit of an 'Art Form' and is one aspect I have struggled with since the start of my SQL experience many years ago. I have learned to live with it - BUT - I do need to tell, and warn, you of the possible problems. Just be aware of what I have reported and you will survive.

Sometimes I may even get an error message box which says I can't detach from the MS/VS shell, so then I need to close and reopen MS (and/or VS) and this seems to clear things so I can then do a clean 'Detach'.

From our .NET code we don't actually do Detach / Attach - we seem to just need to supply a connection string. Anything else may be hidden from us coders by the .NET ADO.NET system.

Finally, you could say why bother when we could do it more simply from .NET code. Well, the answer is that it is VERY useful to be able to use Management Studio to check-out our sample database. Look at the data, run some basic queries etc.. Here is a good and simple place to start :-
We are asking to have returned to us as a data set, all the customers from the Customer table. This simple query is supplied for us by the context menu option - here are the results :-
We will look at making some of our own queries in the next post - queries directly from the IDE in Management Studio (or VS).

See you in the next post,
Phil.
Wales, UK.

Okay Michael and all,

Lets now go a step further and from MS or VS write and apply our own queries to the sample MDF we saw previously.

Without using a 'provided' context menu option we can open a new query pane of our own, and then type in our own query, then execute it against our chosen database.

So lets get a new query pane - see below :-
In the new window / pane I have manually type my own query - a variation of the one we saw the IDE provide previously - check this out :-
Notice in the above image that we need to select the 'Execute' button (or F5) to send the query to the database engine. The MS shell (or IDE) actually provides some intellisense for the script we type in. The SQL query script is called 'T-SQL' and said as "tee sequel". 'Tee' stands for 'Transact'

Lets see the results set we get returned :-
Check that the results are in order of 'City', A - Z.

Now then, we can actually create queries as complex as our simple data allows us to.

Here is a JOIN with filter and sorting :-
You can copy this for yourself, and then create and execute queries of your own. I would often do this before I went to the .NET code and queried from there.

Next stop for us is using the same database from the .NET code - in fact X# code. We will use Linq to SQL where we still operate on Tables. No 'Entities' for a while, we do that later.

Good Luck,
Phil.
Wales, UK.