Navigation


VFPConversion Blog

This blog is dedicate to the adoption of technologies such as Microsoft .NET or SQL Server in addition to Visual FoxPro. Expect posts on this blog to be fairly technical, as this blog is geared towards developers, testers, and technical decision makers.

Content Area Footer

Tuesday, February 10, 2009
Two Extensive Training Classes for VFP Developers - .NET Training for VFP Developers and Converting VFP Applications to .NET



Where: Onsite at EPS Software Offices (6605 Cypresswood Dr. Suite 300, Spring, TX 77379) or remotely via GoToMeeting
When: .NET Training for VFP Developers - March 16-18, 2009 (Monday – Wednesday) - Leverage your VFP knowledge to learn .NET
Converting VFP Applications to .NET - March 19 & 20, 2009 (Thursday & Friday) - Converting your VFP Applications to .NET

EPS Software will be holding two comprehensive classes, specifically for Visual FoxPro developers who wish to utilize the latest Microsoft .NET technologies. The training class will be held at our offices in Houston, Texas as well as online via GoToMeeting. The first class (Monday - Wednesday) will be .NET Training for VFP Developers. The second class (Thursday & Friday) will be Converting VFP Applications to .NET.

These two events will be taught by industry renowned expert, author, speaker, and MVP Claudio Lassala, as well as senior developer and creator of much of the VFP2NET toolset, Mike Yeager.

In the first class, attendees will learn an overview of Visual Studio and the .NET Platform from a VFP perspective, C# and VB.NET, WPF & Silverlight, Windows and Web applications, and much, much more.. The second class will discuss overall strategies, planning, architecting and real world techniques for converting existing VFP applications to .NET. (The full agenda is below.) Attendees will also get the opportunity to discuss their projects and have their questions personally answered by both Claudio Lassala and Mike Yeager.

Costs are the same for either on-site or remote access:
Only $749 for the 3-day .NET Training for VFP Developers class - March 16 - 18. To register for the 3-day class only, click here
Only $599 for the 2-day Converting VFP Applications to .NET class - March 19 & 20. To register for the 2-day class only, click here
Or attend BOTH classes for a discounted price of only $1,199! To register for both classes, click here

Registration is extremely limited. For more information please e-mail info@eps-software.com or call Patrick at 832-717-4445 x 32.
Discounts are available for companies who have previously attended our classes. Call Patrick for details.

For more information, visit www.VFPConversion.com or go directly to the event site here.



Posted @ 7:12 PM by Whitney, Ellen (ewhitney@eps-software.com) -
Comments


Sunday, November 09, 2008
Visual FoxPro: A Dynamic Language?

Over the recent months (or even years), a development paradigm has gained importance that has been around for a while, but hasn't been nearly as popular as it is now: Dynamic Languages.

What exactly is a dynamic language? DLs are languages that are not staticly typed. In most static languages, one creates an instance of an object and at that point, one knows the type of an object and what methods and properties it has. For instance, in C#, we could write this to create an instance of a form:

Form form = new Form();
form.Show();

The fact that form has a Show() method is clear based on the definition of the "form" variable to be of type (class) "Form" (Form form). In fact, the compiler can look up the definition of the "Form" class and verify that it indeed has a Show() method that takes no parameters. If so, the code compiles and runs fine. If such a method isn't found, the compiler refuses to compile the code. This is a great too to improve code and runtime quality of your application.

Dynamic languages approach the process a bit different. They simply allow calling methods on an instantiated object during runtime, with no check members during compile time. Conceptually, we could write this in pseudo-code like so:

form = new Form();
form.ShowNow(); // May or may not work during runtime
 

In some ways, this is actually similar to how Visual FoxPro works, where the same code could be written like so:

LOCAL oForm = CreateObject("Form")
oForm.Show()

No compile-time check is performed in VFP to see whether the Show() method exists or not. It simply invokes the method dynamically at runtime. If it exists: We are all smiles. Otherwise: Crash and burn!

So does that mean VFP is a dynamic language? Well, no, not really (or only partially). The question we need to ask ourselves is "why do dynamic languages make sense in some scenarios?". And the answer to that lies in the ability to add "stuff" dynamically. There certainly is no benefit in not knowing whether a method call will work or not when there is no way to add a method dynamically. Which could happen in the above scenario only if we instantiated a different object. We know Form objects in VFP have certain methods and there is no upside in the compiler not being able to check that, unless we have the ability to really add new things dynamically. In a true dynamic language, we should be able to do something like this (pseudo code again):

form = new Form(); // Has no ShowNow() method!!!
form.ShowNow();    // Crash and burn!
form.ShowNow = function {
                   this.Visible = true;
               }; // Now we have a ShowNow method!
form.ShowNow();   // Works

As you can see, this code doesn't really look like VFP and there is no support in VFP for things like function pointers, delegates, anonymous methods, or lambda expressions (these are all techniques that could be used to create something similar to the above example). VFP does have the ability to add properties dynamically and such, but it is a awkward approach and I have never seen an app that makes large scale use of it, or even bases its entire architecture on it, as would be the case in dynamic languages such as JavaScript, Ruby, or Python. (If you have an example where this is the case, I'd be interested to hear about it).

So is VFP a dynamic language then? Well, it is to a certain extent (examples include dynamic member invocation or eval and macro abilities), but in a lot of ways, VFP takes a static approach without static typing, rather than a true dynamic approach. Some of the basics are dynamic, but the VFP paradigm isn't and VFP lacks some core concepts of dynamic languages such as object alteration during runtime (changing the inheritance tree for instance, or adding lambda expressions).

In .NET, languages such as VB and C# fulfill some dynamic criteria (especially VB gets close in the technology it provides, although not necessarily in how it is used in the wild). C# 4.0 will offer explicit support for dynamic concepts that can co-exist perfectly with the static concepts C# is known for (this is something that gets me very excited). Also, IronPython and IronRuby, two new .NET languages from Microsoft are specifically designed to be dynamic languages only.  

Posted @ 3:56 PM by Egger, Markus (markus@code-magazine.com) -
Comments (14)


Monday, October 27, 2008
PDC Announcement: EPS launches CodeCast podcast

We (EPS & CoDe Magazine) just launched a new podcast called "CodeCast". CodeCast is a companion podcast to CoDe Magazine. This podcast also covers topics that are of interest to VFP developers looking to adopt .NET. This is a weekly podcast for CoDe Magazine. The RSS feed to subscribe is: http://feeds.feedburner.com/codemag/codecast

CodeCastLogo1

I (Markus Egger) am one of the CodeCast co-host, together with Ken Levy and Gary Short.

Each CodeCast show episode should be about 30 minutes even though this first one is about 44 minutes. The file download will typically be just under 100MB since it is recorded and in MP3 format at 320K bit rate for maximum voice and music quality, so it could be called CodeCast HD. (We will also make a lower bit rate available soon for those with less bandwidth).

The first episode introduces the podcast, the hosts, CoDe Magazine, as well as previews the PDC 2008 (Microsoft Professional Developer Conference) this week and several of the technologies expected to make an appearance at the event.

You can also follow the CodeCast on Twitter: http://twitter.com/CodeCast

BTW: There is a special CoDe Magazine subscription offer for CodeCast listeners. Click here to get it.

 



Posted @ 1:49 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Sunday, October 05, 2008
Houston, our Problem is solved!

We are back up and operational! :-)

After several long weeks without power and with several servers down and others semi-operational, we have finally recovered from hurricane Ike and will have the Houston office open as of tomorrow (Monday, Oct. 6th, 2008). Business as usual, I guess :-).

Luckily, we didn't suffer any major damages other than the power outage. If you have been trying to contact us, your emails may have never reached us, since our email server has been down for several days. Please don't hesitate to re-contact us if you are still waiting for an answer.

I'd also like to take the opportunity to thank Network Partners (www.NetworkPartners.com) for their help and letting us use their data center while ours had no power.



Posted @ 9:53 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Tuesday, April 01, 2008
New VFPConversion Events Announced (among others)

EPS has announced new VFPConversion events as well as a few other events. Some free, some for charge. Check them out at http://www.vfpconversion.com/Training.aspx 



Posted @ 4:13 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Thursday, March 13, 2008
General Purpose Languages, DSLs, and (Visual) FoxPro

A lot of people ask me why they should pick .NET over VFP or vice versa. "Why should I use .NET when VFP can do everything I need?", some people say. And the answer is: If VFP does everything you need it to do, then stick with VFP, for crying out loud!

So when exactly does VFP everything you need it to do? Well, here is one way to answer that question:

In the world of software development, there are different types of programming languages. Some are general purpose languages (GPLs) and other are domain specific languages (DSLs). Both types have been around for a long time, but only relatively recently have we started to think about it in these terms. Here's the definition for both types:

  • General Purpose Languages
    GPLs are languages that have been created with very broad goals. GPLs are usually relatively close to the OS or the hardware in the sense that they are designed to make the CPU do just about anything a computer can do. Examples of GPLs are C++, C#, Visual Basic.NET,...
     
  • Domain Specific Languages
    DSLs are created with a much more specific goal in mind. A DSL could be used to manipulate data for instance. Or perhaps they are geared towards creating high performance 3D graphics. Or maybe they are even specific to a point where they solve a very specific business problem, such as workflow, or optimizing power plants. DSLs can be written languages, or they can be graphical languages driven by diagrams. Examples of DSLs are T-SQL, (Windows) Workflow Foundation, HLSL (High Level Shader Language), the .NET Windows Forms Designer, and many very specific things used in specific businesses.

So an interesting question is this: Is VFP a GPL or a DSL?

I would argue that VFP is a DSL. A very large one, admittedly, but still, VFP was created with a very specific goal in mind: Creating data driven business applications on the Windows platform. To achieve this goal, one could argue that VFP is a combination of multiple DSLs: The VFP DML (Data Manipulation Language) to handle data. Then there is the UI definition part driven by SCXes and VCXes. Then there is the report writer. That sort of stuff.

Of course VFP has been extended over time. VFP works on the web mainly by means of COM interop or third party products such as Web Connection. VFP can also import Win32 API features through a special layer. We can talk to SQL Server and then even apply the VFP DML on the retrieved result set. However, all these things are add-ons to the original idea. Everything VFP does natively was specifically created for VFP. When you pop a button on a form, the button is created by VFP. VFP is not driving a standard Windows button, instead, it creates its own.

VFP also can't easily take advantage of general purpose APIs. Just because Windows offers a Direct 3D API doesn't mean that API is easily usable from VFP. Sure, it can probably be done if you tried really hard, but it isn't what VFP was designed for. Just because WCF makes communication in complex systems really easy doesn't mean VFP can easily take advantage of all the compelling WCF features. Just because Microsoft now provides a great platform to create code that can have (security) rules applied to the code's execution, doesn't mean VFP can take advantage of that, and so forth. I once created a monopoly-like graphical game with FoxPro 2.6, and I managed to pull it off, but it sure wasn't what VFP was really good at.

So the question simply is: Is the problem you are trying to solve with your application a problem that matches the domain VFP was created for? VFP was created to build monolithic business application with data that was either local or on a local network. And VFP is really, really good at that. Everything beyond that gets more difficult. You can still pull off a COM based multi-tier system or even a web app, but it sure isn't as easy as it was to build a DBF-based Windows desktop application.

If on the other hand, your problem is slightly different, then VFP is probably not such a good choice. Many modern applications have the need to scale very well, work in a distributed fashion, interop and integrate with various services, run secure, run in a fashion that can be managed by administrators, use modern UIs as provided by WPF, Silverlight, or ASP.NET (Ajax), have to be easily deployable (ClickOnce), run on mobile devices, and generally, do things we didn't worry about 5 or 10 years ago. The visual power and visualization requirements for modern applications have skyrocketed. Amounts of data have grown huge. Applications need to be available online and offline. And so forth, and so forth.

So that is one way to look at the big picture. There are other questions you can ask yourself too. Market pressure for instance. Is your competitor killing you because you are still in a COM or VFP world and they are not? This is a scenario we see every day. But that is a completely different story altogether... :-).

 

Posted @ 2:14 PM by Egger, Markus (markus@code-magazine.com) -
Comments (1)


Thursday, August 23, 2007
Calvin Hsia posts cool LINQ examples and compares them to VFP

Calvin Hsia (former lead developer on the VFP team at Microsoft) has posted some interesting entries on his blog where he explores cool LINQ queries and even compares them to VFP queries. Check them out here and here.



Posted @ 2:55 PM by Egger, Markus (markus@code-magazine.com) -
Comments (4)


Monday, July 02, 2007
Hosting the .NET Runtime in Visual FoxPro

Rick Strahl discusses hosting the .NET Runtime in VFP. Check it out here.



Posted @ 1:51 PM by Egger, Markus (markus@code-magazine.com) -
Comments (1)


Wednesday, June 20, 2007
VFP Forms and Windows Vista Aero

VFP has some problems with Windows Vista Aero. (Aero is the rendering style in Windows Vista that makes window headers and borders appear semi transparent). VFP forms have trouble with this rendering style, unless the user is logged in as administrator (which one typically isn't in Vista).

As it turns out, the problem is related to the way VFP sets some of the properties on a window, which cause the window to be created and then change the border style afterwards. The solution to this problem is to change the order in which windows are created and configured.

Calvin Hsia explains how this is done in one of his recent blog posts.



Posted @ 9:16 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Sunday, June 17, 2007
Are .NET Applications harder to deploy than VFP apps? Not!

I recently saw some messages on messageboards and blogs that seem to spread the rumor that .NET applications are harder to deploy than their VFP equivalents.

Hu?

A lot of arguments go back and forth about whether VFP or .NET is better. People compare individual commands and programming techniques. While I generally think people need to look at the much bigger picture, one can at least see that there is some validity to those discussions. But deployment?!? Pa-leaaase!

.NET applications are about as trivial to deploy as it gets. Copy the files from the dev machine to wherever you want to run the app, and then.... well, there is no "then". You are done. The app runs. It is as easy as that.

You want to create a real setup? No problem. Create a setup project in .NET, point it to your EXE, and voila, there you have your installer. You want your conventionally deployed application to update itself automatically? Well, you can have that too, with the updater application block. Or better yet: Switch to ClickOnce deployment, which automatically performs updates without the need for any special coding on your side. It is easy, and it works extremely well in the real world (check out our Xiine magazine client for an example - www.Xiine.com - you can read VFPConversion articles with Xiine these days...).

Of course there are other scenario beyond WinForms apps. But it really gets no more complicated than this. Sure, some applications require an actual setup (such as Windows Services... but then you can't even do that in VFP, so it would be hard to compare), but the techniques discussed here really cover all scenarios.

So there is no argument here at all. You may hate or like .NET, but a discussion about deployment is just a no-go...



Posted @ 12:07 PM by Egger, Markus (markus@code-magazine.com) -
Comments (1)


Wednesday, March 14, 2007
Microsoft Announcement: VFP 9 is the Last Version of Visual FoxPro

Microsoft has used the currently ongoing MVP Summit conference to announce details about the future of Visual FoxPro. The announcement was made yesterday evening to a group of MVPs and, shortly after, an official announcement was posted on http://msdn.microsoft.com/vfoxpro, as well as on Alan Griver’s blog. The core of the announcement is that there won’t be any future versions of Visual FoxPro. But to take it step by step, here are the main points:

  • Microsoft has officially announced that there won’t be a version 10 of Visual FoxPro. (And no, there won’t be a version 11 or 12 either as someone has already speculated…)
  • Service Pack 2 for Visual FoxPro 9 will ship in summer 2007. The focus of this service pack is Windows Vista compatibility. As with most service packs, one should not expect any major new features (if any at all). The goal here is to fix show-stopper bugs.
  • Visual FoxPro 9 will be supported under the MS Mainstream Support program until January 12th 2010. Extended support will be available until January 13th 2015. So while there won’t be new releases of Visual FoxPro during that time, Microsoft will still support the product.
  • The “Sedna” project will be wrapped up sometime this summer as well. The Sedna components (which are xBase components build on top of Visual FoxPro and will not change the core product) will be released to the community as open source. Sedna components will be completely free of charge. The expected delivery vehicle is www.CodePlex.com. This will allow the community to update and maintain these components, similar to community efforts around the VFPx and VFPy projects.

The exact announcement can be found at: http://msdn2.microsoft.com/en-us/vfoxpro/bb308952.aspx

Today has already seen quite a bit of discussion within the community. Of course, this is not a surprise to most VFP developers, but the general tone still seems to be one of sadness, since so many of us have spent a tremendous amount of time with Visual FoxPro. However, it is important to note that this does not mean that Visual FoxPro is being dropped on the spot. Microsoft continues to sell Visual FoxPro 9, and Microsoft will continue to support Visual FoxPro as described above.

Also, the release mechanism for the Sedna components is interesting and provides a number of opportunities for the community to enhance and maintain these components for a long time to come. If you are interested in what some of these components do, check out our most recent CoDe Focus issue for Visual FoxPro Sedna. You can still sign up for a printed copy free of charge here (as well as other special issues) as long as supplies last. Also, you can read the content online (also free, of course) at www.code-magazine.com/focus/vfp.

Many of the Sedna components focus on making Visual FoxPro work better with .NET. If you are interested in adopting .NET technologies (and you probably are if you read this blog), check out our new tools section (http://www.vfpconversion.com/Tools.aspx). For instance, we recently uploaded a video about the new report converter tool. Check it out at: http://www.vfpconversion.com/Vfp2NetReports.aspx

Also, check out the articles section, which should give you plenty to read up on (http://www.vfpconversion.com/Articles.aspx). And if there is a topic you are interested in that you can’t find an article or blog post about, send us an email (info@vfpconversion.com) and we will try our best to help you out.



Posted @ 3:40 PM by Egger, Markus (markus@code-magazine.com) -
Comments (14)


Thursday, January 25, 2007
New CoDe Focus Magazine for VFP

EPS is about to publish a new CoDe Focus issue (CoDe Magazine special issue). It is called "Sedna: Beyond VFP 9", and that is pretty much exactly what it covers.

The cool thing is that this print magazine is completely free of charge. All you have to do to get it is sign up. However, note that the print-run is limited, and a lot of issues already are claimed. So if you are interested, make sure to sign up as quickly as possible. Here is the signup URL:

http://www.code-magazine.com/focus/interests.aspx

Make sure you indicate that you are interested in Visual FoxPro development.

Enjoy! And feel free to pass this on...

Note: We are planning a few other issues for the next months as well. The signup URL for those is the same...



Posted @ 4:28 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Sunday, December 10, 2006
More EPS MVPs

Many of the 2007 Microsoft MVPs have been announced recently, and for EPS, it was a good round of announcements again. I myself received the MVP award again, as did several other "EPSers" (either direct employees or close partners). Here's the quick list:

Congratulations, everyone!

This continues our proud tradition of supporting the MVP program. To my knowledge, EPS has received more MVP awards than any other company. I haven't counted the total number of MVP awards we got, but it gotta be somewhere between 40 and 50, or perhaps more (just for employees... not counting contractors). (Actually, if someone feels I am wrong and there is a company that received more awards, post a reply. I'd be curious and happy to know who outdoes us).

And that doesn't even count the number of CoDe Magazine authors who are MVPs. It would be interesting to count those too. Since we are so involved in the community, we have a ton of MVPs writing for us...



Posted @ 12:28 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Monday, November 13, 2006
Markus Interviewed on Dr. Neil's PodCast

While I was at DevConnections last week in Vegas, Dr. Neil recorded a podcast that just went online here. Enjoy.



Posted @ 2:20 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Tuesday, November 07, 2006
Microsoft Release Frenzy

TechEd Europe is in full swing, and so is DevConnections 2006 in Las Vegas (which is the show I am speaking at). Microsoft uses these shows to launch quite a series of new products and betas. Here are some of the bigger points:

  • Office 2007 has been released yesterday
  • Visual Studio 2005 Tools for Office 2007 has been released yesterday
  • The .NET Framework 3.0 (including WPF, WCF, and WF) has been released yesterday
  • Visual Studio 2005 extensions for .NET 3.0 has been released yesterday (although many of the more advanced tools for technologies such as WPF are not there yet).
  • Internet Explorer 7 of course has been released just a few days ago.
  • Media Player 11 has also been released recently

Find more information about some of these things on http://msdn.microsoft.com/vstudio.

Of course, one of the big items not on this list is Windows Vista. It has not been released officially at this point, but I would be very surprised if that announcement wasn't made today or tomorrow or at least during these two shows.

Also, there are quite a few betas that have been made available now:

  • ASP.NET Ajax is available in beta 2
  • Visual Studio 2005 SP1 is available as a beta
  • Expression Web Designer is available as beta 1 (not a CTP anymore)
  • Exchange 2007 is available as beta 2
  • SQL Server 2005 SP2 beta is either already available or should be available soon
  • SQL Server Compact Edition (formerly known as "SQL Everywhere") should either be available as a beta or will be soon:
  • Windows Live OneCare is available as a beta now
  • XNA Studio is available as a beta now

And that's not even all I am sure (just blogging a bit in between sessions and meetings). Other things that are coming soon are new versions of SharePoint and also Expression Interactive Designer and Expression Graphics Designer betas will be available in the not too distant future (my guess).

 



Posted @ 4:12 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Saturday, October 21, 2006
Stored Procs for DBs without Stored Procs?

Someone just asked me a good question: Since I said in a previous blog post that we use SQL Everywhere for unit testing instead of SQL Server [in certain scenarios], what exactly do we do with stored procedures? After all, SQL Everywhere does not support sprocs.

The answer is that we use a concept we call "Stored Procedure Facade", which allows us to simulate stored procedures for systems that normally do not support it. This is part of our Milos Solution Platform product. How do we do that? Well, check out this article of mine, which we had in the last Tablet PC CoDe Focus issue: http://www.code-magazine.com/Article.aspx?quickid=0512112. Scroll down and search for the word "facade" to find the details. (Use of Milos not required).

Talking about CoDe Focus issues: We are working on several more focus issues. To make sure you get those issues completely free of charge, tell us which ones you are interested in here.



Posted @ 4:59 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Tuesday, September 19, 2006
OOP, LINQ, and WPF presentations at the Advisor DevCon on the VFP Track

A few weeks ago I’ve been to the Advison DevCon 2006. It was a pretty quick trip, since I’ve flown in the night before, did my three presentations, and flew back to Houston right away.

Despite the fact that I was on the VFP track, the three sessions I’ve done weren’t 100% VFP:

  • Comparing OOP between .NET and VFP: I’ve been presenting this one for 3 years now, and it’s still one I like. When I started to learn .NET, there was one fact that made me learn it a lot faster: the fact that I knew well OOP from all the years working with VFP. Concepts such as encapsulation, inheritance, polymorphism, abstraction, weren’t new to me, and since they’re available (and required) in .NET, that was one less (complicated) thing that I had to learn. Talking to VFP people about how to learn OOP in .NET from a VFP developer’s perspective sure is a fun topic to me.
  • Intro to LINQ (Language Integrated Query): if there’s one thing in .NET that most likely every VFP developer will complain about, that thing is data manipulation. VFP has had SQL built into the language for a long time, and the easiness of data manipulation provided by SQL in VFP has always been one of my favorite features of the product. ADO.NET on the other hand, allows .NET developer to access data, but it doesn’t have any easy way to let the developer query that data once it’s in memory. LINQ is a feature coming with .NET 3.0 (the next version of .NET) that will bridge this gap, providing SQL-like capabilities to .NET languages similar to the ones we know and love in VFP, but even more powerful, since the queries don’t necessarily have to run against databases, but instead, they can be run against any enumerable object (such as an array of strings, a collection of business objects, an XML document… you name it!). Make sure you check out LINQ right now: every VFP developer should love it. http://msdn.microsoft.com/data/ref/linq/
  • Introduction to Windows Presentation Foundation (WPF): This was the session that had less VFP content on it, but on the other hand, it was my best attended one. WPF is the new API to be used when writing Windows applications. Its main purpose is to provide an API that allows developers to write applications that look and feel very professional, using the full potential of the hardware available today. Even though developers can’t write WPF applications in VFP natively, there’s still value in writing the WPF applications in .NET, and then consume it in VFP. VFP is very good at manipulating data, and WPF is outstanding at data visualization; why don’t put them to work together (if that’s what you need)? WPF is another new thing coming soon that every developer (not just .NET or VFP developers) should be looking at: http://msdn.microsoft.com/winfx/technologies/presentation/default.aspx

It’s always great to be able to go out and meet VFP developers, and help them seeing and understanding what other technologies are available out there that they should be considering in order to improve the services they provide to their clients.



Posted @ 5:18 PM by Lassala, Claudio (lassala@foxbrasil.com.br) -
Comments (1)


Sunday, August 06, 2006
SQL Everywhere

Microsoft is adding another member to the SQL Server family: SQL Server 2005 Everywhere Edition, short "SQL Everywhere". This new version of SQL Server aims to be a scale-down SQL data engine that can be used and installed easily, with little impact on security, and few demands performance-wise.

So what exactly is SQL Everywhere? For one, it is not SQL Server. It may share the name with its big cousin, but it actually is a completely different data engine. It is the same data engine in fact, that is used be SQL Server Mobile Edition on mobile devices (Pocket PCs, SmartPhones,...). In fact, SQL Everywhere shares all the object names and APIs with SQL Mobile. For instance, the command object used by SQL Everywhere is called SqlCeCommand ("SQL Server CE" is the original/internal name of SQL Mobile). Really, SQL Everywhere is SQL Mobile, it just runs on Windows PCs now. (Note: SQL Mobile is not the Jet engine as is often incorrectly stated...).

SQL Everywhere is easy to use. It comes as a set of assemblies that can easily be distributed with your main application. Think of SQL Everywhere as an extension of the .NET Framework. It is deployed like any other .NET assembly. It does not require a sophisticated install as SQL Express does. It also doesn't require admin rights to be installed, which makes SQL Everywhere the ideal database for ClickOnce Smart Client applications. Also, SQL Everywhere does not run as a service as other SQL Server versions do. It only gets loaded into memory when it is really needed, because at the end of the day, the entire SQL Everywhere engine is just a set of .NET assemblies.

SQL Everywhere databases are stored in SFD files. A single database is stored in a single SFD file that contains all tables. This approach makes it easy to deploy the database itself, because it is just one more file that comes with the install. It is also possible to put the database files into partially trusted locations (isolated storage). Today, it is possible to build partially trusted ClickOnce applications, but when the app needs a database, one usually had to use SQL Express and the partial trust scenario went out the window(s). SQL Everywhere is a very important step forward in supporting partial trust scenarios for real.

SQL Everywhere is not a functional equivalent of SQL Server though. The biggest limitation of SQL Everywhere is the lack of stored procedure support.

For VFP developers, this whole setup isn't anything new of course. After all, this is very similar to using DBF files in VFP. Except that SQL Everywhere uses a single file per database, while VFP has multiple files per table. Also, SQL Everywhere is accessed through a standard object-based API with command objects and the like, while VFP uses procedural database commands to access and manipulate data. For multi-tiered applications, SQL Everywhere has the upper hand, since procedural data access does not work well in multi-tiered scenarios. On the other hand, SQL Everywhere still doesn't rival the simplicity of VFP's "USE xxx" command.

To provide a quick overview, we now have the following versions of SQL Server available:

  1. SQL Server 2005 (the main thing, which comes in several sub-versions, such as "Enterprise") - This is the big moma. The workhorse of databases designed to handle "serious" database needs of any size in client/server scenarios.
  2. SQL Server 2005 Express Edition  (formerly known as "MSDE") - This is the one you want for serious database needs on the local workstation. It is easier to install than regular SQL Server and just much better suited for local database needs. Be aware that you need admin rights for installation.
  3. SQL Server 2005 Everywhere Edition - This is the best choice if you need a database for an individual smart client application that needs to be installed with as little fuzz as possible, even in partial trust environments.
  4. SQL Server 2005 Mobile Edition (formerly "SQL CE") - This is the database technology for mobile devices. It is also the same database engine as SQL Everywhere.

One use of the SQL Everywhere engine I really like is Unit Testing. Many unit tests have database dependencies. It has been a problem for us in the past to make sure that those dependencies are always available. For instance, our Milos Solution Platform product provides a lot of business logic which requires some database under the hood, be it SQL, Oracle, or XML files. We have unit tests that test this business logic independent of the database (testing the database is a different issue altogether), but we need a database for this stuff to work. So someone sets up a database for this purpose and everything is fine, but then 10 months later, someone wants to run the unit tests at a completely different location (such as our office in Austria) and - bang - the dependency is missing! As a result, no unit tests are executed. With SQL Everywhere, we can now provide a test database and source control it with the unit tests. It is great!

Talking about Milos: The latest version of this product now supports SQL Everywhere natively. It is just a configuration option. And since we put support for SQL Everywhere into the product, we also had the opportunity to take it for a serious test run, and we like what we are seeing! It really works very well.

For more information about SQL Everywhere, check out this article, or visit Steve Lasker's Blog (the MS Product Manager on SQL Everywhere).

 



Posted @ 3:11 PM by Egger, Markus (markus@code-magazine.com) -
Comments (1)


Saturday, April 22, 2006
A Nice Use of Generics

The .NET Runtime 2.0 has a very nice new feature called "Generics". Generics have a lot to do with strong-typing. As you probably know, everything one does in .NET is supposed to be strongly types, since it has such a positive impact on code quality (among other things). However, there are some areas where strong typing had to be violated in .NET up to version 1.1, or - as an alternative - the developer had to do an insane amount of work to get the advantages of strong typing.

One example are lists of objects stored in collections. For this purpose, .NET offers various classes, such as the ArrayList class. An array list can store any object type. For instance, an array list can store form classes:

ArrayList myForms = new ArrayList();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new CustomerEditForm());

This is C# code. If there was an ArrayList class in VFP (or if you created one yourself), it would be used in this fashion:

LOCAL myForms
myForms = CreateObject("ArrayList")
myForms.Add(CreateObject("Form"))
myForms.Add(CreateObject("Form"))
myForms.Add(CreateObject("CustomerEditForm"))

Having collections of objects is very useful in many ways. For instance, we can now iterate over these forms to show them all on screen:

foreach (Form frm in myForms)
{
    frm.Show();
}

Now here is the problem: What if someone stored something other than a Form instance into that collection? An ArrayList can store any object, not just forms. So this would be a disaster:

ArrayList myForms = new ArrayList();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new Button());
foreach (Form frm in myForms)
{
    frm.Show();
}

This would fail at runtime, since there is no way for the ArrayList class to control that only a certain type of object can be stored in that particular instance.

So how can we solve this problem? In .NET 1.1, this problem is solved by subclassing the ArrayList class and changing a number of members (such as the Add() method) to accept only Form classes. The problem with this is that it is very time consuming to do this. One has to create a subclass for forms, another for buttons, another for DataSets, and so on. (Keep in mind that there are thousands of different object types in the .NET Framework).

This is why .NET 2.0 introduces a the "Generics" feature. It allows for the generic definition of classes (such as an ArrayList-like class), but then when it is used, define a more specific purpose. This example shows the new List class, which is a generics-enabled version of the ArrayList:

List<Form> myForms = new List<Form>();
myForms.Add(new Form());
myForms.Add(new Form());
myForms.Add(new Button()); // Compiler Error!!!

In this case, a new List object is instantiated, but it is stated that in this instance, only Form objects can be stored in it. This is defined in the angle brackets. Instead of saying "we instantiate an ArrayList", we would now say "we instantiate a List of Form".

This is very cool, because is is great for code quality as well as productivity.

Now here is a very cool example for the use of generics in a non-collection example: I recently helped a customer to create business rules. The customer uses our Milos Solution Platform (framework) to create their application, and Milos (like many other frameworks) allows for the definition of business rules as classes (this is only one of the ways of doing this... but exact workings of Milos are not the subject of this post). The customer wanted to create a generic rule that allowed them to compare any data field to a value and say "this is only valid of the value is greater than X".

In .NET 1.1, this sort of rule could be implemented through objects that "implement IComparable". Many objects, such as integers, decimals, strings,... implement IComparable. This way, it is possible to say "if (x > 0)", which compares x to 0 and evaluates to true if x is indeed greater than 0. It also allows us to say 'if ("B" > "A")', which evaluates to true, since A is before B in the alphabet. So this works with every object that implements IComparable. Therefore, a method that compares to values could be implemented like this in C#:

public class MyRule
    public bool
IsGreater(IComparable val1, IComparable val2)
    {
        if (val1.CompareTo(val2) > 0)
        {
            return true;
        }
        else
        {
            return false;
        }
    }
}

We can now call this method passing two integers (numbers), since integers implement IComparable. So the following is perfectly valid:

MyRule x = new MyRule();
x.IsGreater(10,5);

The following is also valid, since strings implement IComparable:

MyRule x = new MyRule();
x.IsGreater("Athens","Rome");

So far so good. The only gotcha here is that both passed parameters need to be not just of a type that implements IComparable, but they in fact need to be the SAME type. In other words: This would not work despite both parameters being IComparable:

MyRule x = new MyRule();
x.IsGreater(10,"Rome");

And this can be a bummer, because sometimes this gets confusing. A typical failure scenario would be one where two different numeric types (decimal and integer for instance) are passed. What we need is a way to implement this as generically as demonstrated here, but when the method is used, it needs to be restricted to a specific type. And once again, this can be done when the same method is implemented through generics:

MyRule<int> x = new MyRule<int>();
x.IsGreater(10,20);
x.IsGreater(10,"Rome"); // Compiler Error!!!

I thought this was a very nice use of Generics. It saved us from having to create potentially hundreds of different strongly-typed rules and still get full compiler quality checking.

BTW: A little while back I blogged about the creation of a Length data type. At the time, some readers discussed whether there was a real advantage over creating a new data type, or whether the same advantages could be achieved through methods and objects implemented in VFP. This business rule example is a good demonstration of why it is advantageous to have custom types. The Length type I created in this example can be used with this same business rule class like so:

MyRule<Length> x = new MyRule<Length>();
x.IsGreater(new Length("5 foot 6 inch"),new Length("1m 25cm"));

There is no difference between the usage of this custom type and the intrinsic types. As long as the custom type implements IComparable, it will work in all the scenarios all the other types work.

BTW: If you are interested in more info about generics, check out the following CoDe Magazine search link:
http://www.code-magazine.com/SearchResults.aspx?search=Generics

 



Posted @ 6:06 PM by Egger, Markus (markus@code-magazine.com) -
Comments


Wednesday, April 12, 2006
LINQ

LINQ stands for "Language Integrated Query" and is a new feature that will be available in .NET 3.0 ("Orcas"). FoxPro developers can envision LINQ very similar to the FoxPro DML (Data Manipulation Language). Think "SELECT commands in C#/VB.NET" and you are right on the money. Of course, one of the big differences between .NET and VFP is that .NET does not differentiate between data and objects. This means that in LINQ, SELECT commands run against all kinds of sources, including lists of objects and XML documents. (And of course regular data).

I recently had an article about LINQ in CoDe Magazine. The article can be read online at the CoDe Magazine site as well as on VFPConversion.com:

There also are a few shorter articles on LINQ on this site:

Another interesting article that discusses LINQ's XML support (also known as "XLINQ") can be found at this URL:

LINQ is a very interesting technology, especially for VFP developers. After all LINQ introduces features that remove many of the .NET pain points for VFP developers. Looking at LINQ, it is obvious that much of the VFP spirit went into LINQ. Some even say this could be considered to be VFP 10. I am not sure that I would go quite that far, although those people do have a point...



Posted @ 9:00 PM by Egger, Markus (markus@code-magazine.com) -
Comments


More Posts: Older Posts

 

 

 

 

 

 

 

Syndication RSS 2.0 RSS 2.0

All My Blogs:
My personal blogs:
Dev and Publishing Dev and Publishing
Travel and Internat. Living Travel and Internat. Living
Other blogs I contribute to:
Milos Blog (US) Milos Blog (US)
VFPConv. Dev Blog (US) VFPConv. Dev Blog (US)
VFPConv. Dev Blog (DE) VFPConv. Dev Blog (DE)

 

Blog Archives
All Blog Posts

2009
    February (1)
2008
    November (1)
    October (2)
    April (1)
    March (1)
2007
    August (1)
    July (1)
    June (2)
    March (1)
    January (1)
2006
    December (1)
    November (2)
    October (1)
    September (1)
    August (1)
    April (3)
    March (2)
    February (1)
    January (1)
2005
    December (2)
    November (3)
    October (2)
    September (7)
    August (3)
    July (4)
    June (12)

 

 

 

This Blog is powered by MilosTM Collaboration Components.