The LA Fox Developer Newsletter

December 1998

Better VFP (Con't from page 6)

MSDN: Where does Visual FoxPro 6.0 fit into Microsoft’

Windows DNA platform architecture for building three-tie

applications?

RIVARD: Visual FoxPro 6.0 is designed primarily to build really

good two-tier applications. We’ve offered really good client-

server support since Visual FoxPro 3.0. Visual FoxPro applica-

tions can talk to ODBC data sources, for example. Our users

like that because it makes all data appear just like native Visual

FoxPro database information. They don’t have to learn a new

technology to import data from SQL Server or other sources.

That said, Visual FoxPro 6.0 can plug into the front end or

middle layer of a three-tier application. In order to extend Visual

FoxPro 6.0 into this n-tier space, we have our COM server

technology. This lets developers write middle-tier business logic

components that can access data on the server

Once an application has called one of these middle-tier compo-

nents, it can use all the power of the Visual FoxPro language.

Not the visual parts of the language, since the component is

running on the server, but the Visual FoxPro engine and parts of

the language, its OOP model. So in the n-tier environment,

Visual FoxPro can live on the middle tier and interoperate with

other tiers. The other side of the story is traditional FoxPro

developers. Many of them only want to build one- or two-tier

applications. They may choose to write their front ends as a

rich client using Visual FoxPro 6.0, and tie that client into back-

end services using technologies in Visual Studio or BackOffice.

MSDN: So developers can use Visual FoxPro 6.0 to build the

front end or middle tier of their n-tier Windows DNA applications.

Can they use Visual FoxPro 6.0 on the third tier, the back-end

data store?

RIVARD: When it comes to scalability, Visual FoxPro is great

as a local database engine. But we think many developers will

prefer to use SQL Server on the back end, especially if they

want enterprise-level features such as security, transactions,

and other high-level features that are available in SQL Server but

not Visual FoxPro. Whether or not a developer uses Visual

FoxPro, SQL Server, or another data store on the back end

depends on their business needs. It depends on their business

and scalability requirements. We don’t try to compete against

SQL Server in that area.

MSDN: How can Visual FoxPro developers take advantage of

the Web? I haven’t heard you mention the Web yet.

RIVARD: There are two different ways to go about building Web

applications in Visual FoxPro 6.0. The main way is to use

Visual FoxPro automation servers on the middle tier, to have

Active Server Page objects talking to FoxPro objects. This lets

Visual FoxPro do all the work on the middle tier for accessing

data, and in many cases even producing HTML. The FoxPro

language is inherently good at manipulating and merging text. It

lends itself really well to producing HTML on the fly like this.

Another method of building Web applications with Visual

FoxPro 6.0 is to use ISAPI. Visual FoxPro has an ISAPI layer

that allows developers to take a regular FoxPro form—complete

with form controls, data binding, and everything else—and

transform it into HTML. When users click on your Web page or

Web application, the ISAPI layer transforms the presentation

into HTML, even if you designed your FoxPro form as a middle-

tier server.

MSDN: What did your development team do in Visual FoxPro

6.0 to help developers address the year 2000 issue?

RIVARD: This was a big deal for us. We determined that

developers already could produce Year 2000-compliant applica-

tions in Visual FoxPro 5.0, but in Visual FoxPro 6.0 we tried to

make it easier. In Visual FoxPro 5.0, there are ways developers

can produce non-compliant applications and not realize they are

doing it. Specifically, Visual FoxPro 5.0 allows developers to

add date constants to their code that use two digit years, since

Visual FoxPro 5.0 has an algorithm that can interpret two digit

years. The ambiguity of not knowing if a two-digit year is 1900-

something or 2000-something can cause unexpected behavior.

To eliminate this issue, we added a feature called StrictDate to

Visual FoxPro 6.0. When you turn on StnctDate, the compiler

will choke if you try to use two digit years in your code. This

new feature also allows FoxPro developers to take older code

built with Visuai FoxPro 5.0, Visual FoxPro 3.0, or even FoxPro

2.6, and recompile it with Visual FoxPro 6.0. The new compiler

can then check it for two-digit years.

We also addressed another class of Year 2000 issues related to

how software generates constants on the fly. In the past, if

developers wanted to generate data on the fly, Visual FoxPro

made them compose it in a date string, have that string parsed,

and then produce the date. The problem with that method is that

parsing strings can lead to errors if you haven’t formatted the

string right. So we added some features to Visual FoxPro 6.0 to

generate dates based on numeric values.

Together, all of the new Year 2000 features in Visual FoxPro 6.0

should really help developers scrub their applications and

prepare them for the Year 2000.

RIVARD: Visual FoxPro 6.0 improved our MTS support, adding

a level of scalability that pleased many customers. But other

customers really wanted us to push scalability even harder.

We’ll address that in the next release.

The next release of Visual FoxPro will focus on improving

scalability in middle-tier servers. Our customers are adopting

more and more middle-tier technology because of the Windows

DNA architecture. They want to do more with Visual FoxPro on

the middle tier. This may not sound like much, but technically

it’s a very big thing for us. It means we’ll pour a lot of time and

(Con't, page 12)

Page 7