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.
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).
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!!!
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.
XSharp Development Team
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.
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).
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.
The next step in me helping new guys to get into SQL with X# will take me a little bit longer than usual. (A day or so.) This is because I will use the notes in the Appendix 'X' section of my "ClickStartLINQ" eNotes to make a small test app which will access the MDF we used previously with Management Studio. So I will be coding from scratch - just to show how it is done, and because my old C# and Vulcan demo apps are in a bit of confusion after 8 years of changes - so a clean start sounds a good idea.
Here is what I will be using to guide me :-
And here is where my copy of the MDF exists / resides :-
Wish me luck !
You can be trying out new queries for yourselves in Management Studio, or VS 2017.
For those guys who are unfamiliar with SQL use and operation from coded .NET apps, getting a working connection string which finds both an Instance of a SQL server and the data file, is a VERY good first step to making a working app.
If you have followed my posts so far (like Michael) then this small app should work for you.
Here are a couple of images to show you what you should get :-
And now the WPF form but without the data in the 'DataGrid' control - grey and at the bottom of form.
I will now add the extra (but still small) amounts of code to allow us to return and show the Customer table data.
SqlConnectionStringBuilder has properties for all the different connection string parameters,
so rather than doing oSCSB["Data Source"] := "xxxxx" which is of course susceptible to typos, you should be able to do oSCSB:DataSource := "xxxxx" which is a bit more reliable and should give you IntelliSense help.
Good point ! This is a small problem coming from me using old, but working, code from way back and then the good old copy and paste ;-0)
I was focusing on getting guys into using real live SQL data ASAP, so that is my excuse.
Also for your knowledgeable ears, I do intend to get from L2S (Linq to SQL) to L2E (Linq to Entity) as soon as possible. It was just that L2S makes a nice simple in between stage for guys new to all this stuff.
this was interesting. Finally, I was able to run the app. The concept is more or less clear but a lot of questions are popping up.
1. There is nothing like a "dbServer object" that takes care of all these SQL connection strings?
2. There is no "automated" class generation for all the SQL table fields? Means, hand-written code is the solution. In case of multiple large tables, we need to do this by ourselves?
In other words: a visual "SQL stuff builder", where I select the SQL Server, Table, fields and the "builder" creates the rest does not exist
3. Syntax of X#: there are quite a few unknown commands to me. e.g what does "local implied" mean. Also, it looks like I can define variables somewhere in the code and not necessarily at the beginning. How can I look up the definition?
4. WPF is also absolutely new to me. Based on my research WPF is the way to go. Do I need to learn (besides X#, SQL) also XAML?
As of today, this seems to be an intersting journey. I think as a next step for me I need to digest the code and try to re-build it by myself. I am pretty sure I need to cheat and look at Phils code. Especially the SQL connection stuff looks complicated...
I am really glad you managed to follow along, and I hope a few others may do so as well ;-0)
As for your questions, well many/most of them will just disappear when we take the next step to EF6 (entity framework) where we have similar code BUT deal in 'Entities', which is really .NET complex classes. We give up thinking in tables, and all the relational mapping is easily sorted out for us, once we define our entity classes. So all is done in .NET code, like what we are used to.
The only reason I used 'L2S' was because it proves a useful stepping stone to get to EF6, and it allows us to see how EF simplifies things on the SQL side of things.
I understand you need time to try out, and digest, the stuff we have seen so far. I did the same with Nick Friend's MVVM sample - three weeks I sat there I seem to recall ;-0) But I got there in the end.
As for WPF, we will use it in a 'simple and straight forward' way - still very powerful however.
When we use the EF6 approach we will first define the Entity classes, and then the code will create the database for us - its called 'Code First'. This is the approach I like to use - BUT - as you have seen, with L2S we can easily use existing data tables.
Using EF6 we will also see how to populate our database from entities, which automatically place data in the correct and most suitable Tables.
When we use EF6 we can effectively forget about SQL, all we MUST do is use LINQ to deal will all our collections of object items.
No doubt I will have some other useful points in the morning.
And remember, we have done all this with a "Virtual Machine", and with software which is FREE from Microsoft and also the X# Team - all it cost you was a few Euros, for a Windows upgrade and some time and effort to work with me
Hope you sleep well after the mental efforts and brain activity.
I have another (extended) sample to post, it will help you go further - more simple sample code to copy and adapt etc..
Here is an improved but not finished sample output :-