X# Core - which way?

[Anonymous]

Hi All,
Now that I have my little sample app working I need to get into it but I do not want to head the wrong way, so I have a few questions:
Using the X# Core how do I access SQL servers? MS-SQL
Comparing to VO, what are the limitation in respect of capabilities? Classes? Add-ons?
Where do I find a reference of the available functions of X# Core ?
If there is an article related to these please point me there, but any help is appreciated
TIA

Tom

[robert]

Tom,
X# core (at this moment) does NOT have any functions. It has only the .Net data types and methods available.
Once our runtime is ready to the general public (it is only available to subscribers at this moment) then you will also be able to use typed functions like Left(), Substr3() etc.

Robert

[wriedmann]

Hi Tom,

with Core you can use Ado.NET or the Entity Framework.

I use (the old way, I know) the classes in System.Data.SqlClient.

You can use the class SqlConnection to open a connection:

Code: Select all

_oConnection := SqlConnection{}
_oConnection:ConnectionString := ConnString
_oConnection:Open()
 _lConnected := self:IsConnectionOpen()

and then retrieve a datatable:

Code: Select all

oAdapter := SqlDataAdapter{ cSelect, self:Connection }
oDataSet  := Dataset{}
oAdapter:Fill( oDataSet )
oDataTable := oDataSet:Tables[0]
oDataSet := null_object

or execute a SQL statement:

Code: Select all

oCommand := SqlCommand{ cStatement, _oConnection }
nReturn := oCommand:ExecuteNonQuery()

Wolfgang

[lumberjack]

Hi Wolfgang/Tom and everybody else following,

with Core you can use Ado.NET or the Entity Framework.
I use (the old way, I know) the classes in System.Data.SqlClient.
You can use the class SqlConnection to open a connection:

Not to forget the DbProviderFactories which allow Database agnostic code:

Code: Select all

VAR oProvider := System.Data.Common.DbProviderFactories.GetFactory(sProvider)
VAR oConn := oProvider:CreateConnection()
oConn:ConnectionString := sConnection
VAR oComm := oProvider:CreateCommand()
oComm:Connection := oConn
oComm:CommandText := strSql
oConn:Open()
VAR oReader := oComm:ExecuteReader()

Regards,

[Terry]

Hi Tom

Believe me I do appreciate the difficulties of initially getting to grips with things in the .Net arena. It is vast, but although implementation may be hugely complex, I can assure you that understanding it all is much, much easier.

There are basically only two challenges ahead for anyone, one which you already know, is learning the language syntax, the other is the array/matrix of functions available to you from the .Net Framework which exists on your machine within mscorelib (Multi-Language Standard Common Object Runtime).

The mscorelib array of functions is vast. There is no way, I could pretend to understand them all. (nor, I suspect could anyone else). This means basically you have to learn a subset as needed.
It also means that for any average developer there is a huge amount of code that will never be used, and for Microsoft a need to make all this available and downloadable in one go. (consuming link bandwidth and so on unnecessarily).

So, at this time (June 2018), we are seeing a transition to parcelling things up into manageable chunks. This is what .Net Core is all about. My advice to you would be: just keep it at the back of your mind for the time being and don’t worry about it.
VO brought about a major simplification in software development: namely it automated all the underlying electronic control, thus relieving the developer from any need to even think about it.
Beyond that, my advice to you is just forget about the way VO was implemented – (pay homage to it and its’ developers if you like, but that’s all. Seriously it was a brilliant bit of foresight).
.Net embraces that automatic control of electronics – garbage collection – something over which your programs can take control if you need to, but that’s for later.

As I said above, implementation of things is complex. It is Visual Studio that orchestrates things overall: basically, we are enabling VS to accept a simplified manual input from us as developers and translate that into full, accurate and concise control over all constituent elements.
Clearly, we have to set up Visual Studio to do this.
(Conductor/orchestra is not too far off as an analogy)

As Wolfgang said somewhere you are entering a far broader arena than ever existed with VO.

It is the setting up of VS where I think you are having problems. In the orchestra analogy we don’t want a violinist amongst the brass. In VS violins are grouped into the strings section and trumpets the brass. To get some handle on what is grouped into what:- in Solution Explorer take a look at the references and see what has been referenced automatically – you’ll soon see and get used to the groupings.
Just to encourage: I said understanding was much easier than implementing. Well you’ll come across many things which whilst terminologically different actually mean the same thing in another context. So, understanding becomes so much easier if you can build on meaning rather than implementation.

I am not qualified nor able to make any comment re XSharp or XSharp Core. Everything I say is my take on .Net in general and C#. However, since XSharp is built to address the CLR, there should be a reasonable read-across.
Others here are far better qualified and able to help with XSharp than me.

Nevertheless, I do hope this helps a bit. If this is the sort of thing you’re after I can try and summarise it diagrammatically.

Best Regards
Terry

[tom@dieselworks.com.au]

Thanks Terry and others for the guidance. I think I am getting it, but I can see the light is still far... but at least progressing.

Re: "VO brought about a major simplification in software development: namely it automated all the underlying electronic control, thus relieving the developer from any need to even think about it."

I like to reflect my view on this as it may help to steer things to some extent. While my history with the binary world goes back almost as far as it could in respect of my childhood, I was introduced to the Binary world in grade 7, I learned to build little calculator, would be ambitious to say computer, from AND & OR gates in the mid 70's and was programming Canon Canola SX320 if I remember correctly in the early 80's in machine language doing regression lines, so one can guess I am not afraid of these things, but I honestly think that converting business logic into code and doing system/low level programming is similar to having very good memory and being very logical, somehow most people gifted in one or the other but seldom both.

VO gave us the ability to implement complex business logic without being concerned about the underlying layers of system code. this is why some of us stayed with it for so long. I am not afraid of C#, C or even low level programming, but I am not interested, and have no time for it. What I want is implement/convert business logic into code and not to worry about all kind of intricacies of the OS, compiler and so on. I know this is likely to remain a dream, so here I am looking forward to minimise the compromise

[Terry]

Hi Tom
I am sure the sentiments of your last paragraph accord with those of most people here.

I take the view that Software Development is about both communication and implementation.
How do we encourage (or force) the user to put the data in correctly, in the first place then how do we provide an output which leaves, ideally, no room for misinterpretation?
There is no way, in todays’ world that anyone could do it all from scratch. Instead a .Net enabled language enables us to integrate bits and pieces from all over the place.
If some bits are not quite what we want we can modify them.
For example, learning the intricacies of WPF is a major time-consuming task on its own. So we could probably find some library which does the job for us.
Of course, we could use notepad and write a program to link all this up. It would work if we did it right and hadn’t gone mad in the process.
How much easier to set up Visual Studio to link it all up for us.
We can do this if we arrange our code in a way which the compiler understands, and VS can control.
All we need is to arrange things in a standard way.
Namely group everything into the same thing – a namespace and then “nest things” further down as required.
We can give each namespace a name and that allows us to spread its code over a file structure of our own choosing.
VS then allows us to change names etc so they reflect our thinking.
By doing this, things match the way we think as human beings – we can arrange our code to address things at a fairly shallow level over a broad range, or at detailed level over a narrow range. Not both at the same time.
Everything in .Net is a type. We start off with an assembly which is simply obtained from our solution file structure as per MS Build and project Files, then we have namespace and at first level of nesting we have a class. Nested within the class we get fields – standard OOP stuff.

Hope that hasn’t muddied the waters too much.
Terry

[lumberjack]

Hi Tom,

VO gave us the ability to implement complex business logic without being concerned about the underlying layers of system code. this is why some of us stayed with it for so long. I am not afraid of C#, C or even low level programming, but I am not interested, and have no time for it. What I want is implement/convert business logic into code and not to worry about all kind of intricacies of the OS, compiler and so on. I know this is likely to remain a dream, so here I am looking forward to minimize the compromise

I think you sum it up very well.

Knowing Pascal V4+ /Delphi there are a lot of it in what you see today in how .NET programming languages work which I believe helped me when I started with Vulcan:

The one advantage we have with using X# as development tool. All our business logic sitting in VO can with minimal effort brought into .NET.

From a front-end perspective we have to do some work if we make the decision to move to Forms/Entity Framework/WPF, but that is life.

The big advantage is that .NET is language agnostic. My X# can consume C#/VB.NET assemblies, I can subclass any other language class and make them X# and vice-versa. No DLL hell.

Well not as "fluent" as Terry's post, but I hope you understand.

Regards,

[wriedmann]

Hi Tom,

I will try to add my point of view: VO gave us the possibility to work at a high level of abstraction, but also to go down to the level of a C/C++.
X# should do the same: you can work with the Core dialect - like C#, or use the VO/Vulcan dialects with all known functions, array, codeblocks, weak typing and late bound code.

The only thing that is missing currently, but will come with the time, is a GUI and data access library.

Wolfgang

[tom@dieselworks.com.au]

Thanks All,

This helps a lot, and I guess will other newcomers too. You guys certainly helped to clear up a few things but now I have a new question: What should I do? Should I start trying to convert one of my apps? or wait ? what can I convert, and what not? actually the NOT is what I like to know!

Also I have no Vulcan, so what are my choices?

TIA

Tom