Question for VFP and SQL Server programmers

[iolair]

If there are any programmers out there who have used both VFP and SQL Server, can you tell me which language is easier to program in? Are there any huge advantages of one language over the other? Struggling with deciding on which product to use.

Thanks.

Iolair MacWalter
Network Engineer

 

[Olaf Doschke]

It's not that hard to do queries in SQL Server, it's still sql. You may have been used to just choose the table to report on and are not familiar with SQL, but you can still do that when the data is in SQL Server.

You create a DSN in the ODBC Administrator and then in VFP need 2 lines to have data you can report on:

handle = SQLConnect("DSNname","User","Password")
SqlExec(handle,"Select * From Table","cursor")
Copy To some.dbf

So not having DBFs you're used to is easily replaced by this. Next step is reporting on some.dbf, or you move to reporting services, also part of the SQL Server suite. Lots of options. You can also switch to list&label or some other reporting tool.

Bye, Olaf.

 

[JRB-Bldr]

using VB might be "quicker"

I hope you are referring to VB.NET and not one of the older versions of VB.

There wouldn't be much point in developing something today in an older version of VB like VB6.

If your old 20-year-old application is an older version of Foxpro, then your quickest and easiest migration path would be to VFP9.

Otherwise, based on vast differences in how you programatically accomplish things in VB vs. FP or something else, you will have to design and develop the entire thing FROM SCRATCH.
Keep that in mind when you are planning your man-hours time/cost estimates for development.

Good Luck,
JRB-Bldr

 

[clipper01]

Ok , clear now , this is about continuiy of 20 year old app

Agree with JRB , to your in-house dev who reckons VB is like VFP , would say he is NUTS .

Have done this conversion a few times i.e. take 15yr old app written in FPW2.6 , that is FoxPro for Windows 2.6 , about late 80's vintage and just run under VFP9 , There is a little bit of clean-up to do ,some screens/reports will get a bit mangled , but easy to fix . Put the job out to tender for some VFP dev to do and you will then have a system working in VFP9 that can be supported as long as there are VFP dev's left alive ( Go to ebay or where-ever , buy a copy of VFP9 while still available, get your VFP dev to upgrade to SP2 and your'e done )

 

[iolair]

Yes, it is an old FoxPro 2.5 app. If we do go VB, it will be latest version for sure. And yes, I am planning on man hours for complete re-write.

I had thought of farming this out. That's possible.

Thanks to all for the input. You guys are the greatest.

Iolair MacWalter
Network Engineer

 

[JRB-Bldr]

I am planning on man hours for complete re-write.

Keep in mind that it will not be as easy as a 're-write' to change a FP application to VB.

Hopefully you have fully specified documentation on all aspects of the entire FP application and those documents are very in-depth.

This will be needed because EVERYTHING (all algorithms, data accumulation approach, etc.) about the original application will need to be totally recreated using a totally different programing methodology.

This effort will be like creating a totally new application working off of the existing documentation. You have one small advantage in that the users can contribute their knowledge of how they have been using the application, but it is very unlikely that they know what is going on "under the hood" when they click OK.

You might think of the task as similar to taking a book written in English and translating it to Chinese where you can't even say a simple sentence in the same manner from language to language.

All of that "under the hood" logic, etc. will need to be re-created from scratch.

Good Luck,
JRB-Bldr

 

[craigber]

@Iolair: You are correct that going to VB.Net would be quicker with a VB background. However, I've talked to LOTS of people who were vb 6.0 devs and found moving to VB.Net harder than moving to C#.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[iolair]

I hadn't considered C#. Is it anything like C or C++? I can write very simple programs in C or C++, but not sure my programmer knows either.

Yes, we are in the process right now of gathering user input, checking all the changed business rules, etc. So far we've found that there are lots of things that were built that were never used, lots of things that could easily be done that haven't been done. So, I'm having to re-open lines of communication, become an instant diplomat, etc. It's tough, but it's also fun, and a real learning process.

The original documentation from 20 years ago (before I was hired) is sketchy at best, so that will be an additional task for us to perform on this project.

Iolair MacWalter
Network Engineer

 

[Olaf Doschke]

You've got to understand that .NET languages all are translated to common language and ru by the common language runtime (CLR) - exceptions to the rule have come in with languages of a DLR = dynamic language runtime, but that doesn't matter here.

Both VB.NET and C# translate to the same code and you actually can decompile VB.NET to C# and vice versa. More important is, that you are forced to create more seperated modules for each layer of an application and so you can combine VB-NET and C# assemblies to a whole application. The choice of C# vs VB.NET really is a bit more a choice on the liking of a syntax. VB.Net has a more verbose syntax, where C# like C++ or C uses curly braces {}. And that's just one observation of many.

Essence is, you don't need to worry much about choosing either one langauage, they are quite equal. Maybe Craig can tell you, why he prefers and suggests C# over VB.NET, I can't.

C# is by no means a successor of C++, it continues with a C/C++ like syntax, but the main engine of .NET languages is the .NET runtime/framework and to learn that. The real successor of C++ is C++0x from a very strict perspective of the history and downward compatibility viewpoint. C# is said to rather resemble Java in a more modern C like syntax.

Bye, Olaf.

 

[clipper01]

agree with above Iloar ,I'm also a VFP old-timer , as I said in prior response

"vb.net or C# , both languages are much the same , the language is easy in both cases , the hard part is that the language is just a tool to use the dotNet framework which is VAST "

the similarity to old VB6 is just about a similar name and a few key words.

You will find that once u start in dotNet , you will be googling for days/weeks , "how do I do this /that ..." and you will nearly always get better answers from the C# guys , mainly as they tend to be the most skilled. There may be some other techie reasons that Olaf/Craig etc can clarify , but the above reason was for me the clincher.

So if plan to go dotNet , go C# and approach everything with a fresh mind , do NOT try to shoe-horn things back into the old ways.

 

[iolair]

Thanks. I think I need to get outside professional help on this. You've all been very helpful, and I think what I'm asking for is too much for one programmer here to handle.

The original 20 year old program was contracted out, and it took three professional programmers almost three months to write the original program, something I didn't know until today, when I talked to the business manager about the original program.

I would like to be able to maintain the program in house, so I will make sure my programmer is very involved with the rewrite, if we get to contract it out.

Iolair MacWalter
Network Engineer

 

[JRB-Bldr]

Just a comment so as to assist you in managing your "Business Manager's" expectations.

Since you are changing to a Totally Different Language, you should stop referring to this effort as a 'rewrite' and instead think of it as 'Totally New Application Development'.

The term 're-write' causes some people (especially managers) to minimize their expectations of the effort/time/etc. involved. It makes it seem like a somewhat trivial or minimal effort.

Better that they think of this effort in the same way they did on the first development effort, since this new development effort will quite likely be no less and possibly more.

Another suggestion, in addition of having your in-house programmer very involved would be to get the contractors to DOCUMENT, DOCUMENT, DOCUMENT and you critique their documentation for usability.

Yes you will most likely have to actually pay them to document their work, but it will work out in your best interests in the end - especially 6+ months after they are done and/or have disappeared from the development pool.

Good Luck,
JRB-Bldr

 

[iolair]

jrbbldr, you are so right, my programmer has blasted me several times already for calling it a rewrite. And he's right, it's not a rewrite, but a totally new application development. At least I'm not calling it a conversion project.....but that's another story.

Yes, I will make sure that the contract specifies DOCUMENT and a review of that documentation before final payment is made.

I don't mind paying them for the documentation at all, and in fact, I feel pretty sure the business office would want it that way.

Thanks!

Iolair MacWalter
Network Engineer

 

[JRB-Bldr]

a review of that documentation before final payment is made.

I'd recommend reviewing the documentation LONG BEFORE the final payment comes due.

The contractors will not appreciate it if they have put Hours into creating documentation as they went only to find at the end of the project that is not acceptable to you.

Check and critique their documentation right-out-the-gate so that if modifications to format, content, comprehensiveness, etc. can be adjusted early on. That will eliminate a LOT of Headaches when you get to the final payment coming due.

Good Luck,
JRB-Bldr

 

[iolair]

jrbbldr, thanks again. Makes good sense, and with all we've been worried about, I unfortunately hadn't really thought about that. Thanks for pointing it out.

Iolair MacWalter
Network Engineer

 

[craigber]

Olaf is correct in what he says about .Net.

Think of C# as an entirely new language that has similarities to C and even Java.

I chose C# because it seemed more natural to me compared to VB. Also, the company I worked for at the time was a C++/Java shop and C# fits that better.

If I were to decide between the two today, I would still go with C# because it seems there are more people that are C# devs vs. VB. There also seems to be a bigger demand for C# devs over VB.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[clipper01]

choose C# + Sql Server a good first step , be interested in Craig's experience in other top-level choices. If u are contracting out the job , it might depend on what the "shop " does , but a factor to consider might be , when all this is done , do u plan to have your in-house guy maintain it . If so , these might be considerations
1) WinForms versus WPF. WinForms very similar to old style VB , WPF more geared to fancy graphics, but u need to learn XAML and Blend.
2) 3rd party contrls like DevExpress. They add fancy graphics instead of battle-ship grey , but measns yr in-house guy has to learn them , + u have to buy dev license etc of u want maintain in-house.
3) 3rd party frameworks like nHibernate , again if the 'shop' uses them , that is easy for them , but very difficult for your in-house guy.

So as u can guess , my bet would be keep it sinple , WinForms , no fancy 3rd party additions