Hi.. many I know many of you from Clipper, VO, Vulcan or CULE. Met t many CA events great memories and travels.
It just proves you cannot stand still as your favourite products and environment and devices will continue to change.
Competition now from younger players, qualified professional training, Cloud, open-source major major impact.
Soon to embark on the .NET learning curve and seemed to have joined xSharp at great time in its great leap forward. Hope to contribute along the way. Ales Suchac works for me strong .NET , C# and C++ and VO developer. He developed for us a Native Postgres Dataserver system which allowed us to port from DBF/FPT to SQL. This written around the "libpg.dll".. it is not ODBC which I found not up to scratch.
All the code will be donated to the xSharp projects.
So Hi and the journey begins.
New xSharpees.. or is X#phobes
New xSharpees.. or is X#phobes
Phil McGuinness
New xSharpees.. or is X#phobes
Hi Phil,
Welcome and thank you for announcement!
Wolfgang
Welcome and thank you for announcement!
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
FoxProMatt
New xSharpees.. or is X#phobes
Hi Sherlock - Welcome to X#. I'm new here myself (2 months or so). I'm from a Visual FoxPro and C#/Sql Server background. I look forward to being on this journey with with you, and hopefully we can all contribute make X# the best it can be!
New xSharpees.. or is X#phobes
Hi Phil
> It just proves you cannot stand still as your favourite products and environment and devices will continue to change.
Yes - but the way programs work does not change and the way a digital computer works means they never will.
Apart from Vulcan, which I skirted around, I have the same sort of background (now largely forgotton).
Having said that, for some long time, whilst witnessing the ever greater complexities and capabilities of program development or "coding", I have tried to think how the "learning curve" could be eased.
I have come to the conclusion that this can best be done by looking at things from a "human, real-world perspective", and have outlined this in a post on Chit-Chat made a few months ago entitled "Dot Net from the Ground Up".
It is not finished - many other things have taken priority. But the general gist will, I hope, resonate with a few readers. And more importantly help some.
Good to make contact again.
All the best
Terry
> It just proves you cannot stand still as your favourite products and environment and devices will continue to change.
Yes - but the way programs work does not change and the way a digital computer works means they never will.
Apart from Vulcan, which I skirted around, I have the same sort of background (now largely forgotton).
Having said that, for some long time, whilst witnessing the ever greater complexities and capabilities of program development or "coding", I have tried to think how the "learning curve" could be eased.
I have come to the conclusion that this can best be done by looking at things from a "human, real-world perspective", and have outlined this in a post on Chit-Chat made a few months ago entitled "Dot Net from the Ground Up".
It is not finished - many other things have taken priority. But the general gist will, I hope, resonate with a few readers. And more importantly help some.
Good to make contact again.
All the best
Terry
New xSharpees.. or is X#phobes
Hey Phil,
I am not so expecting this. I look forward seeing your PostgreSQL Dataserver lib.
I am about to start my own DBF lib that will work with PostgreSQL with Devart dotConnect for PostgreSQL. I already have a bulk data conversion tool from DBF to PostgreSQL using a pgLoader.
Regards,
Rene
I am not so expecting this. I look forward seeing your PostgreSQL Dataserver lib.
I am about to start my own DBF lib that will work with PostgreSQL with Devart dotConnect for PostgreSQL. I already have a bulk data conversion tool from DBF to PostgreSQL using a pgLoader.
Regards,
Rene
New xSharpees.. or is X#phobes
Rene.. I think I will get Ales Suchac [ Mr Postgres ] to give the code to Mr Data.. first.
Let us see as a community how we should document and proceed with this.
My interest originally was to get my internal systems which had massive memo databases and running slow on a Peer to peer network to SQL backend. So code that looked VO, Fieldgets and Fieldputs was working one day DBF the next day PGSQL and was very readable to a VOer.
There are like 5 datatypes in DBF [ D,L,C,N,C,M,O ]
Postgres is like 60+ datatypes it was a lot of work to support the full potential of the native DLL.
It is done and it works and it is very fast. The change to uses was 20 times speed increase.
So I will ask Ales to document what he can and say some samples you can identify with.
Let Robert look it and I would like the community to give the feedback to develop as an open source project.
We will keep working on it.. bugs extra features and he is very good with SQL and VO lets hope XSHARP.
I am sure VO DBF developers to PG SQL this is a good option.
Phil
Let us see as a community how we should document and proceed with this.
My interest originally was to get my internal systems which had massive memo databases and running slow on a Peer to peer network to SQL backend. So code that looked VO, Fieldgets and Fieldputs was working one day DBF the next day PGSQL and was very readable to a VOer.
There are like 5 datatypes in DBF [ D,L,C,N,C,M,O ]
Postgres is like 60+ datatypes it was a lot of work to support the full potential of the native DLL.
It is done and it works and it is very fast. The change to uses was 20 times speed increase.
So I will ask Ales to document what he can and say some samples you can identify with.
Let Robert look it and I would like the community to give the feedback to develop as an open source project.
We will keep working on it.. bugs extra features and he is very good with SQL and VO lets hope XSHARP.
I am sure VO DBF developers to PG SQL this is a good option.
Phil
Phil McGuinness
New xSharpees.. or is X#phobes
Looking forward to this one. I also hope, .NET Core 3 support is also being considered on X# new RDD.
Now that .NET 5 will merge 3 .NET frameworks by 2020, exciting years ahead.
Just got overloaded with so much good news in BUILD 2019 where Ginny basically following with UWP/WPF/WinForms elevations to full status as part of Windows UI Framework which soon include "XAML Desktop".
and I have yet to get get started. Got stuck with good old VO.
Now that .NET 5 will merge 3 .NET frameworks by 2020, exciting years ahead.
Just got overloaded with so much good news in BUILD 2019 where Ginny basically following with UWP/WPF/WinForms elevations to full status as part of Windows UI Framework which soon include "XAML Desktop".
and I have yet to get get started. Got stuck with good old VO.
New xSharpees.. or is X#phobes
We are using "normal" .Net classes in the all the new code in the runtime, including the RDD system. So it should work with .Net Core as well. Of course the VO GUI, VO SQL layer, and Internet classes are based on Win32 and will not work on .Net Core 3
The compiler can already do .Net Core. The only real problem is the VS integration , in particular the new project file format.
Robert
The compiler can already do .Net Core. The only real problem is the VS integration , in particular the new project file format.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
New xSharpees.. or is X#phobes
Hi Robert,
This is great. I am planning to new X# RDD to work with my dotConnect thing working on .NET Core 3 to make my data lib works faster. Which I hope.
Thanks for the confirmation.
Rene
This is great. I am planning to new X# RDD to work with my dotConnect thing working on .NET Core 3 to make my data lib works faster. Which I hope.
Thanks for the confirmation.
Rene
New xSharpees.. or is X#phobes
Terry
snip[ but the way programs work does not change and the way a digital computer works means they never will. ]
I have to disagree so much rechanges that require difference approaches and different types of developers.
It just not business logic and pick menu click a button world. Technically code on an off stack hard changes.
My business is divided into two types of developers,, web and say desktop. The desktop on premises is a hard sell now even if the product is mature and working. The Y generation want something different and they are getting it. At stage is was 90/10 desktop now it is 5/95 cloud and losing clients I have had for over 20 and no complaints or service or price. Cloud or nothing. They will not listen,, the people looking will not listen.. the IT person does not help.. it is doomed market in some areas. But cloud wow absolutely flat out and 2 acquisitions in last 2 years and looking for more where it is 1 or 2 web developers.
Build systems for Desktop and cloud very different approach. Code on process works the same for sure but the nature of user interaction the devices the mobile nature the concept of dashboards, automated services and not coming to office is big.
I have desktop guys fighting the trend so hard. Two of may largest competitors about 2 years ago removed the desktop teams and 1 has former as sub contractor for emergency work but the teams are totally different personnel.
When I went to early VO from Clipper sessions then it was apparent 80% would not make the change to event drive systems and that is what happened and I think 80% will never make the true Cloud move.
We migrated a large VO system to later Desktop system and now being ported to cloud. Total different language, look feel, reporting, hopefully rescue some business logic, different developers and interesting the speed to get that port happening. Very fast. Look becomes what dashboards user permissions allow rather than menu with buttons missing or greyed out. What dashboard for your phone verse you desktop?
Phil
snip[ but the way programs work does not change and the way a digital computer works means they never will. ]
I have to disagree so much rechanges that require difference approaches and different types of developers.
It just not business logic and pick menu click a button world. Technically code on an off stack hard changes.
My business is divided into two types of developers,, web and say desktop. The desktop on premises is a hard sell now even if the product is mature and working. The Y generation want something different and they are getting it. At stage is was 90/10 desktop now it is 5/95 cloud and losing clients I have had for over 20 and no complaints or service or price. Cloud or nothing. They will not listen,, the people looking will not listen.. the IT person does not help.. it is doomed market in some areas. But cloud wow absolutely flat out and 2 acquisitions in last 2 years and looking for more where it is 1 or 2 web developers.
Build systems for Desktop and cloud very different approach. Code on process works the same for sure but the nature of user interaction the devices the mobile nature the concept of dashboards, automated services and not coming to office is big.
I have desktop guys fighting the trend so hard. Two of may largest competitors about 2 years ago removed the desktop teams and 1 has former as sub contractor for emergency work but the teams are totally different personnel.
When I went to early VO from Clipper sessions then it was apparent 80% would not make the change to event drive systems and that is what happened and I think 80% will never make the true Cloud move.
We migrated a large VO system to later Desktop system and now being ported to cloud. Total different language, look feel, reporting, hopefully rescue some business logic, different developers and interesting the speed to get that port happening. Very fast. Look becomes what dashboards user permissions allow rather than menu with buttons missing or greyed out. What dashboard for your phone verse you desktop?
Phil
Phil McGuinness