RC.EXE Failed and dbserver

Frank Maraite · Post by **Frank Maraite** » Thu Apr 13, 2017 6:32 pm

Hi Phil and others,

I know what you want me to do, at at the end I will of course. But for a (hopefully) short time I have to be compatible to DBF. Point. The reason is not important here.

But I what I did in the past: I did an interface to DbServer, that hides it's details. Unfortunatly I am not ready to show this detail completly for cologne. I try to get a Observable Collection from DbServer, work on it with DataGrid and sent it back. The same thing then I can do with SQL later without affecting my views, business objects ... .

Hope this makes sense to someone.

Frank

Phil Hepburn · Post by **Phil Hepburn** » Thu Apr 13, 2017 10:27 pm

Hi Frank,

Sounds like a sensible plan of action. You have obviously thought it through.

For many guys in the X# Forum I feel there is a difference between being able to use SQL in their main apps, and starting to learn SQL stuff, and build up SQL skills in coding etc.

Its never too early to start learning some SQL, even though it may take time before SQL can be used in the developers work for customers.

Its not like WPF/XAML where new screens can be put in place right next to older WinForms, and even VO GUI. This can be done a bit at a time, and gradually move over to the newer technology.

Changing from DBF to SQL is a real definite Black / White thing, all or nothing. But, without enough skills the change will never happen, so developers have to be ready for the opportunity with skills already learned.

Hope this helps a few, at least think about SQL, or even dream about it

Thanks for your comments and contribution Frank.
Cheers,
Phil.
Wales, UK.

wriedmann · Post by **wriedmann** » Fri Apr 14, 2017 6:04 am

Hi Phil,

Changing from DBF to SQL is a real definite Black / White thing, all or nothing. But, without enough skills the change will never happen, so developers have to be ready for the opportunity with skills already learned.

There is an option: a mixed environment. New development could be made on SQL, and older functionality remain in DBF. And step by step the DBFs could be changed from DBF to SQL.

My largest application currently has the main data in DBF, but important data also between Oracle, MDB and MySQL. For new development in this application I'm using more and more the SQL backends.

Wolfgang

Phil Hepburn · Post by **Phil Hepburn** » Fri Apr 14, 2017 10:10 am

Yes, I realise this Wolfgang, and it is a good strategy I feel.

However, you are not exactly the average user, AND, it sounds as if you are motivated to moving to SQL

- as a longer term goal.

I also bet that you did some test apps with SQL tables, and test data to get to know SQL, before you started to add small functionality to your existing DBF apps.

Years ago, when I looked at my DBF VO apps with the thought of moving across to SQL, my problem was that I had coded my VO such that I had lines of code everywhere which used a DBF access style ;-0(

Yes, I know it was the mistake of a beginner, and a guy not used to Objects! But I have a feeling that others will have done the same. So unless guys have planned for a change of back-end data source, they will also have a Black / White situation for their existing code and data access.

In the UK we have the local saying of :- "Hindsight is a marvellous thing ! "

Maybe you can share more details with others as to how to go about this problem / situation, and "change".

In may case my two big customer firms completely re-wrote my app in .NET and based them on data in SQL Server 2005. I was paid as an adviser and also converted all of the DBFs to SQL tables with a .NET app I wrote specially. I still have this around if needed by others.

Oh! one firm did it properly and also by one guy doing C# for 18 months. His SQL solution was good and had a table set which did not change in number - "small is beautiful!". I had a good look at his finished solution, very nice.

The other larger firm went with an outside third party 'big firm' of IT consultants to implement a SAGE solution, based on a code engine of SAGE's and an SQL 2005 data server. This conversion was a nightmare, and the table set grew in number each month by 200, yes, I said two hundred. At least their mess kept me in a job for a few years while I supported them (my original customer) with SQL reporting and the likes. And I learned to use Visual Studio better too.

I suppose we could say .... "Big is ugly!" Or it was in this case.

Hope this interests a few. Either way, the DBFs went for ever, never to come back, and the network performance of SQL was more like what they both needed.

Regards to all, and Happy Easter (well Good Friday at least).
Phil.
Wales, UK.

wriedmann · Post by **wriedmann** » Fri Apr 14, 2017 10:19 am

Hi Phil,

I'm using SQL for more than 10 years now.... So I have my experience....

My main problem stays not with the large customers where I maintain my software regularly - there is no problem with SQL as I can install and maintain it when needed. My problem stays with the myriad of small customers without any network or with a small peer-to-peer network of 2 or 3 PCs..... There DBF works and don't need maintenance, and no SQL database except maybe SQLite can do the same. In such installations software is installed copying files, and when they change PC, they don't even need my assistance: they copy the folders and the thing works.
This is the place where I will miss DBFs....

Wolfgang

beerhand · Post by **beerhand** » Mon May 01, 2017 5:38 pm

Hi Phil,

already May. I have installed Visual Studio 2017 (Dev) as well as SQL Server 2016 - all vanilla. I did some "SQL training classes" at Microsoft Virtual Academy - I would say (theoretical) fundamentals are set. I am ready to go if you are!

I installed xSharp into VS. Anythink else I need to setup/prepare?

Best Regards,
Michael

Phil Hepburn · Post by **Phil Hepburn** » Wed May 03, 2017 8:50 pm

Well done indeed !

Give me a day or two to recover from my return journey from Cologne, via four days site-seeing in Gent, Belgium. Returned 20.00 hrs yesterday (last night).

If you now have all the parts in place then we may be well advised to use an existing (simple) database and export it to your system, where we then use Linq to SQL ('L2S') to access the data.

At first when the DB is in place, we can use the Visual Studio IDE facilities to see the tables and the column / rows, and query some data returns.

I will get my head back into this tomorrow - please remind me if I fail to post anything in the next couple of days.

Best regards,
Phil.
Wales, UK.

P.S. I have some useful sample databases ready here and some details on getting Management Studio 2017 too.

beerhand · Post by **beerhand** » Wed May 03, 2017 9:08 pm

No worries at all - take your time.

I experienced some difficulties with SQL server 2016. It caused some strange behaviour on my PC so I had to de-install. I will try to get SQL Express up and running and hope this will not cause any trouble (with you

and my machine).

Michael

Phil Hepburn · Post by **Phil Hepburn** » Thu May 04, 2017 9:55 am

Michael,

It would probably be best if we continued this discussion under the Chit-Chat in the public forum.

I will move my next contribution to it now ...........

Regards to all,
Phil.

Main menu