Conversion from VFP -> C# (with SQL back-end)

[GriffMG]

I don't know if anyone is interested, but I thought I'd give you an update.

After watching most of Bob Tabor's course (or perhaps that should be his 'sales spiel') on C# I dived right in.

Initial progress was actually blinding. I reached my first milestone of being able to create a self-updating application that could find new versions of itself on the web or locally on a LAN, could search for SQL servers, locate appropriate databases and even create the first inklings of a new database a little ahead of schedule.

Then I ground to a complete halt.

A simple three column table and a DataGridView. C# equivalent of the VFP grid.

The client is very, very keen to have a spreadsheet-like interface wherever possible - C# has a nice tool, and it has a 'NewRow' feature at the bottom, just like Access does... but it behaves very strangely to a VFP programmer. It took me a long, long time to understand that you have to think 'disconnected' from the database. It's like the whole model is based on allowing errors and then letting the database reject things when you commit them, rather than validating them and then being 99.99% sure that your data will be successfully written.

That is a gross over simplification, but it is how I was working.

Last night I had a little ephithemy though, and found a way to get the DataGridView to work like VFPs - writing back to the SQL db on (what seems like) a record by record basis. The only snag is that you need two unique fields to do it, the regular ID primary key (which the DataGridView doesn't want to give you when you add new records) and another unique element to do validation against.

I've not tested it against significant datasets yet - it may prove woefully slow - but for my first table it is working ok - I think...



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[clipper01]

have not tested this , but believe a way to get around prob is

assume you are using reg strongly type ADO.NET datasets

a) the prob is , if add record to dataset , the PK field is null , so when you try to update db , you get error , will not allow nulls
b) solution , in dataset make the PK field autoinc but with inc of -1 , when u write that to the DB ( it is now happy / will never find duplicate ) it then gets assigned corrct PK key and writes it back to the dataset

the other approach might be to use ROWGUID's rather than an autoinc integer PK , this is actually what you would find quite frequently in Access apps

or finally , bite the BIG bullet and use WPF instead of Winforms

 

[GriffMG]

Thank you Clipper01

a) I got totally and have a workaround for it... but your b) might be better than my workround... if I use it with my immediate write technique...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[craigber]

So, how did you implement this application? Was it the typical Microsoft demo of drag a data table onto a form and bind it to the controls? If so, then you are getting what should be expected.

Disconnected data is not a .NET thing. That's how VB6 worked. That's how Java works. That's how the web works. Even VFP supports disconnected data.

But you should be looking at a solid 3/n tier model. Perhaps a good application framework will help you. DevForce from IdeaBlade is one option there.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[GriffMG]

Hi Craig,

I don't quite understand, but I'm such a luddite that doesn't surprise me!

I didn't start with a demo at all, I just got a copy of VS2010 and started coding - I have no framework to go from, I didn't even think of doing that. I appreciate that this 'disconnected' thing isn't exclusive to .Not, but it's very new to me.

So is OOP, for that matter.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[clipper01]

kind of agree with griff , can not get my head around why we must use n/tier abstract business layer etc ,just to satisfy the purists

1) will my back-end ever change from sql-server to oracle // NO
2) will my front-end change from Winforms to WebForms to WebService // NO
3) will "Add-New-Stock-Item" be called from several places // NO

so what is wrong with just pop-up a screen , ask for name/category/sub-category etc ??

otherwise u have to use some kind of wrapper around wrapper around wrapper around ado.net ??

 

[clipper01]

griff , just curious , what is your client's objective for the re-write e.g.
1) it has some current problems/ deficincies
2) he just wants the "exact same" app but written in dotNet /SQL Server , in case you are run over by a bus ( presume there is some source code continuity deal)
3) he wants it to " look modern" , ie same function , but more eye-candy
4) he wants some new features
5) bought some other 'ERP/accounts' systems , so just needs a fraction of the old be-spoke system
6) some other

reason I ask is that I suspect in most cases , #2/5 would apply to my apps and it has a big bearing on the flavour of dotNet that I would use

 

[Olaf Doschke]

Clipper,

1) will my back-end ever change from sql-server to oracle // NO
2) will my front-end change from Winforms to WebForms to WebService // NO
3) will "Add-New-Stock-Item" be called from several places // NO

Even if you make these statements out of years of experience, you should consider that world more and more goes to service oriented architetures and that asks for the decoupling of things.

Smartphones and tablets are now used very frequently to also do things while on the move. And bringing the data to these devices also profits from services in the one or other incarnation, as SOAP or RESTful or other services, which do concentrate on very few aspects and are better maintainable, can be better tested or developed teamwise, with the seperation of concerns. Why should a programmer know design or why should a designer know programming?

As a one man business you're better off with a seamless integration of things, of course, but you should perhaps think of creating a network of specialists working on projects.

Last not least: The three above statements look like a bet you will want to win, and will perhaps lead you to insisting on them more than you will want some time in the future. It's not wise to make such statements, you will just be sticking to them to not admit you were wrong. That's perhaps just a very pessimistic prediction from my side.

As what you criticise are rules of OOP, and well, maybe very puristic rules, think about it from an evolutionary point of view: OOP has been introduced in all languages, the only exception being assembler perhaps. Even VFP offers OOP since over ten yers, perhaps even much, it was already in VFP6, when VFP crossed my way.

OOP is the winner of software evolution, so to say. Once you embrace the rules OOP you will see, that they don't restrict you in the first place. Once you did that overhead of seperating things you are now confronted with, which needs more code in the first place, you will benefit from it. That class code will be even better reusable than functions and procedures. It can combine and recombine to more complex things quite easy, once you have built your foundations.

Yes, non OOP code can also be reused, can also be clean. But often enough the argument you mainly give, that you will not want to ever reuse something rather comes from your experience, that you can't, even if you would want. See at something more abstract and you see that there are common things you only need to write once and can reuse, even in totally different applications.

In the end every little task you now redo is not that much overhead, that you ever got the feeling you're missing reusabilty. But once you understand the power of OOP inheritance and reusabilty and encapsulation and decoupling you will see it also helps you as a single developer/designer/producer/project manager/tester to do things the OOP way.

You now are just hitting the frustation of needing to relearn what you already could do much faster. You will overcome this. The outset is, that .net offers so much more, VFP isn't capable to do. And you can't say that you will never make use of that anyway, just because you never did in the past.

Bye, Olaf.

 

[GriffMG]

Hi Clipper

Why does my client need/want to rewrite the app? There are three reasons really.

1) It's old and DOSy and it doesn't look so good when they bid to use it to control the costs of multi-billion pound projects.

2) They would like the data entry to be much more like a spreadsheet - rather than a form based approach, because the users are used to spreadsheets and feel they are easier to use.

3) There is only one person who can maintain the existing system, and he's getting on a bit...

It has taken them nearly a decade to get the money to do this, and you can't knock them for trying to make it last as least as long as it's predecessor!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[clipper01]

olaf , I do agree with all that u say , dotNet/OOP is the only game in town . Yes I've used Linq2Sql , excellent , until M$ of course drops support in vs2010 in favour of EF. I've used Silverlight, can u really build a LOB app without report writing ??. and u have to jump through hoops with all the async WCF stuff. Then WPF , u have to buy Expression Studio , have u tried using the vs2010 WPF designer. Then u have to try debug XAML that has no debugger. C# is a superb language , ado.net is an excellent implementation .

Or do u want to use some other ORM like nHibernate , takes 6 month to figure it out , or DevForce , which is another onion-layer wrapper around EF .

Like griff , I have to deliver to clients who are not multi-nationals billionaires , so my take is to use the best of dotNet ( C# and ado.net ) , and nothing wrong with WinForms either.

Don't want to sound negative , that is def not the case . My honest belief is that VFP was/is the best ever dev platform for small data-centred apps and the nearest dotNet equivalent is WinForms/ADO.net. and yes , use all the OOP of that combo

 

[GriffMG]

I agree about VFP, shame it has been deprecated.

There is no faster RAD environment, and if you can't do it with VFP, you can't do it (that's actually stolen from Clipper, but it is nearly true).

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[clipper01]

interesting that the 'clincher' for the re-write ( + little matter of revenue ) was the spread-sheet style entry . Once u figure out how do that , it works right through the app , u can then sub-class the datagridview to then make it a standard behaviour , voila , OOP in action !!

sean m

 

[Dan Freeman]

if you can't do it with VFP, you can't do it (that's actually stolen from Clipper, but it is nearly true)

When FoxPro/Windows came out, and it was clear it would be a good long time (if ever) before the world saw a Clipper for Windows, we saw a large influx of Clipper devs into the Foxpro community.

The questions always started out "where do I find a library for..." because, of course, that's how you added functionality to Clipper. Every clipper dev had standard libraries they used. The answer, almost invariably, was "you don't need one, it's built in".

 

[GriffMG]

I always added functionality to Clipper by writing something in Turbo C (Clipper was written in C, and that made it really rather easy - and helped someone who knew C work well in Clipper, at least so I have always thought).

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

clipper,

I also agree again with what you add. MS has done some moves with LinQ and Entity Framwork, with WPF and XAML, that leads to the need of many changes from version to version or is yet still incomplete in regard to debugging, for example.

As a developer using some technology you want stability and extnsion, not the need to migrate from one to the next technology.

With a decoupled design and clever inheritance, you will need less changes in the one point of your classes persisting data, than if you incorporate LinQ in all levels of your code, of course. And yes, LinQ is intended to not only use it towards SQL server, but towards XML or Objects or Datasets. But these flavours of LinQ are also not touched by Entity Framework and remain functional and are extended with LinQ to Entities.

For the prices of the dev tools: You get them for fractions of the price, if you get a ms partner (which is free) and use programs like the action pack. Nobody pays the single product prices.

Bye, Olaf.

 

[clipper01]

Olaf , am sure u know of these ,( but might be of interst for VFP developers/just starting to dabble in .Net,) here are 2 great resources ; the VFP toolkit allows you to use C# equivalents of all the VFP functions , but more to the point , the included help file shows the C# source for doing all of the VFP equivalensts of eg date/string handling etc. a great way to help build your own class libraries as you correctly reccomend

http://foxcentral.net/microsoft/vfptoolkitnet.htm

this is also the best intro to LINQ and SQL , IMO

http://www.linqpad.net/

and both are FREE !!

 

[Mike Lewis]

Clipper,

Thanks for the reminder about the VFP Toolkit, which is a valuable resource.

When I first saw it a couple of years ago, I remember thinking I wish I had found it earlier, as I had just made a feeble attempt of my own to write some of the VFP string-handling functions in C#. If I ever dabble in C# again, I'll definitely use the Toolkit.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[clipper01]

Griff,
Just curious , wondering how the "re-write" to dotNet is going , there have been a number of similar threads over the last few months.

 

[GriffMG]

I hate it...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[GriffMG]

Just to expand on that slightly, it's become a project that drives me to do almost anything else - any displacement activity is preferable to working in C# -> SQL...

I loathe the way the DataGridView works, and how inconsistent it is with various controls - the way the events and methods fire for text boxes is different for check boxed. I have no option but to use it, thank you Mr Client. If I had been allowed to work in VFP, he would be winning work right now - with a finished system, bells and whistles added.

That said, I am making progress, and once I've learnt how to wrestle C# to do something useful, it's not hard to use that as a template for the next thing, not really OOPing it in the sense that purists might prefer - but getting there.

I could go on, but I won't

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.