A ramble on Visual FoxPro (II.)

Is Visual FoxPro out of date?

With all due respect, I am really tired of hearing such a problem. I have listened to this question for several years. From the rumor to the present, the version of Visual FoxPro has changed two times, the Visual FoxPro 6.0 and Visual FoxPro 7.0, which was launched in the spring of 2001. According to Microsoft's official message, Visual FoxPro 8 (probably the name) is already under development. I'm not sure if there will be visual FoxPro 9.0 (it's like I'm not sure if Microsoft was still there at the time). It can be said that as long as there is no accident (such as the collapse of Microsoft, the industry has undergone major changes, etc.), Fox will be a smooth development!

In foreign countries, a programmer, a company to see their use of development tools as an investment, as a Visual FoxPro development company Microsoft must protect the investment interests of customers, this is a very basic business principles, Microsoft is absolutely afraid to eliminate the 500,000 users of Fox, Unless you never want to earn the money of these 500,000 users.

Why are there rumors of visual FoxPro to be eliminated, I am not very clear. But over the past two years, Microsoft's FoxPro attitude towards visual propaganda has contributed to this rumor. In addition, visual FoxPro is indeed a misleading product, the primary user is very easy to produce a "bad" judgment, and then add that rumor produced "Visual FoxPro really want to be eliminated" illusion.

Why is visual FoxPro a product that is easily misunderstood? I summarize the following reasons:

Object-oriented and process-oriented contention

We say that Visual FoxPro is an object-oriented language and is based on it. Object-oriented languages must have four features: Abstraction (abstraction), Encapsulation (encapsulation), Inheritance (inheritance), polymorphism (polymorphism). Contrast visual FoxPro, is not supporting these four characteristics!

Of course, Visual FoxPro is a long history language like C + + and object Pascal, so there are many process-oriented morphemes in the language. I know that many schools teach students to use visual FoxPro-oriented language features, while ignoring object-oriented teaching, the same problems exist in the vast number of visual FoxPro programmers. We must understand that the Visual FoxPro is not an object-oriented language because we do not use Visual FoxPro-oriented, and that it is as naïve and ridiculous to say that the sun is eaten by the heavenly dog because it rains and does not get out of the sun.

We know that Visual FoxPro's operations on data follow a process-oriented approach over the years, which is quite different from the current development tools. I think that Microsoft is doing so with its own reasons:

First, process-oriented data processing can give full play to the flexible and casual features of the Xbase language system. This, you have used other database development tools, and then use Visual FoxPro to understand.

Second, not directly providing object-oriented data processing components, does not mean that users are not allowed to encapsulate their own data processing components. Many of the best Fox programmers will be encapsulating their own specialized data processing components, this is the noble realm of Visual FoxPro programming!

Record-oriented and set-oriented contention

According to the author's shallow cognition, the relational database processing can be divided into the oriented recording operation and the set-oriented operation.

The client cursor system supported by various development tools is a record-oriented operation that supports absolute positioning between records, and more clearly, it is possible to navigate between records, such as SKIP, go, and so on. Visual FoxPro is undoubtedly the absolute master of this way, the development of language in the 20, gathered a large number of document-oriented language elements. This is because of this, we will repeatedly emphasize: Visual FoxPro cursor System flexible, powerful!

All kinds of large databases, such as Oracle, SQL Server is a representative of the collection process, look at the Orthodox SQL language, there is no data navigation, data records are equal, all have to talk about relations, pendulum conditions!

With the development of technology, people began to notice that the two types of data can not be separated from the operation, so the large database to support the banner, Fox also supports the specification of the SQL language.

Product positioning results in Visual FoxPro change is not easy for people to feel. Microsoft wants to use Visual FoxPro as a middle-tier development tool for a three-tier architecture (or multi-tier architecture).

What is a three-tier architecture? The first layer is the user interface: it contains the user interface, let the user input, output, query and so on; the third layer is the data layer: it is used to place the data, generally refers to the back-end database, including Oracle, SQL Server, etc., it is mainly to provide a large place, to have the rules of the storage of data The second layer is the business logic layer (middle tier): Someone is going to say: access to data, jump directly from the first level to the second level can you? Of course, no one rules can not take shortcuts, and from the database directly grasp the information, both fast and good, then why make a second layer?

Business rules are constantly changing, such as working from 8 o'clock to 10, how does the computer know that the boss is less than two hours away from the recession? It must not know, you have to tell it, then the problem comes, if you have a lot of computers, such as: 100 units, you have to change a new program. If this is a Web program that hangs on the Internet, does it always make it impossible for users to download new programs?

More importantly, in the presence of a large number of customers in the environment, the traditional two-tier architecture is not able to undertake a great deal of work pressure, must be through some kind of intermediate system to achieve pressure balance, which is the middle layer of another magical use!

The middle tier is code written without a graphical interface design, and is the OOP way of code writing, not only familiar with the characteristics of the background database, but also to consider the characteristics of the front interface tools, the most important is the structure of business logic, but also requires knowledge of IIS, MTS (COM +), NT security settings, such as complex and boring things. Interestingly, the various improvements in visual FoxPro in recent years have been more of a work in these areas, with the latest version of Visual FoxPro 7 adding a few features in this area, let me use four questions to illustrate the contribution of visual FoxPro in developing the middle tier:

Question one: Can Visual FoxPro develop a stable, efficient server program? Can, in the visual FoxPro SP 3 released in 1999, Microsoft has given visual FoxPro the ability to develop the inner components of multithreaded processes, And added a new Run-time library VFPnT.DLL (n represents version number) to support its run, in this runtime, remove a lot of old-fashioned and interface control elements that make it smaller. However, because the visual FoxPro6 itself is not very stable (plus SP4 or SP5), this great feature is not fully played under visual FoxPro 6 until Visual FoxPro 7 appears to make it appear a hero!

Question two: How to implement distributed transaction and dynamic load balancing? Visual FoxPro 7 has good support for COM +, which can be solved by COM +!

Question three: How does a client Exchange data collection with the server as a server program? This is the Achilles heel of the server program developed by Visual FoxPro 6, and we know that visual FoxPro is used to process data, but not being able to freely exchange data sets with the outside world can greatly reduce the efficiency of development, use, and program operation! In Visual FoxPro 7, our XML can quickly and easily transfer large data sets to truly free the data set. Now back to the visual FoxPro 6 we used the kind of "loop + attributes" approach, there is really heaven and earth feeling!

Question four: Can you allow Visual FoxPro to develop the server to be used by customers, what do you want to do? You can, in Visual FoxPro 7, provide a completely new function: Execscript (). With it, you can execute multiple client-side statements that conform to the Visual FoxPro specification: You can define variables, do queries, update data, modify table structures ...

Microsoft does practice the promise of letting Visual FoxPro run in the middle tier. But unfortunately: because of the level of domestic users, domestic software applications, the majority of Fox Fans can not feel the rapid changes in Visual FoxPro-for them, Visual FoxPro really "did not change"!

Can Visual FoxPro only be limited to desktop application development?

Technology in progress, the application of software technology is constantly widening, the Internet has been a number of development tools to support the application of the field. Visual FoxPro continues to expand support for the Internet from version 5, and the latest visual FoxPro 7 adds support for Web service. We can divide visual FoxPro support for the Internet into three major parts:

First, simple HTML conversion. The "Web Publishing" of visual FoxPro is this type of tool that leverages HTML and DHTML templates to support the web of visual FoxPro data, a fully static web support.

Second, it is suitable for enterprise internal use of Active Document technology. The active Document technology is the best choice if you want to transform your Visual FoxPro application into a Web application quickly and easily. It supports the app program running in IE, its disadvantage is that the client must install the Visual FoxPro runtime, the client and the database is still a tight stateful relationship, belongs to the F/S architecture-only the interface can run in IE. Its rapid development and its still based on the traditional architecture, it is decided that this technology can only run within the enterprise, generally can not be published in the wide area network.

This technique was proposed by Visual FoxPro 6, when there was a special menu item in the Tool menu. By today's visual FoxPro 7, this menu item has been canceled, but it's not that visual FoxPro 7 doesn't support active Document, but it's not necessary to put it in the eye-catching position anymore.

Third, web-based applications based on COM.

Visual FoxPro can really be used for web development, which is supported by COM.

Here you have an understanding that, as a database development tool, visual FoxPro is not a tool for developing web interfaces such as Fronpage (perhaps future visual FoxPro will support the development of web interfaces). Visual FoxPro is entirely a server running in the background of a Web site, providing services for a variety of applications. COM components written with visual FoxPro can be supported by IIS and run in the background-this is the true Visual FoxPro Web application and the middle tier of a typical multi-tier architecture!

At this stage, Visual FoxPro support for the web can be divided into three levels:

1. Foxisapi.
   This is the first technology, when the ASP technology has not yet appeared, we in IIS can be through ISAPI technology to achieve dynamic web development.

2. Web Server
   ASP technology has emerged, we know that a major feature of ASP technology is to support the application of server-side components. COM components written with Visual FoxPro can be run in IIS for ASP invocation.

3. Web Service
   This is the new feature of Visual FoxPro 7 and the most current technology. The biggest difference with Web service is that the Web Server component can only be invoked through an ASP program, and Web service is available to any system on a global scale, regardless of the client's hardware platform or software platform, as long as it supports SOAP and supports XML.
   More exaggerated said: As long as the Internet, you can enjoy the services provided by the WEB service!

Some people may ask: I can use VB, VC + + to create object components, why do I use visual FoxPro to build the same components? Microsoft has a special comment on this issue: fast, repetitive use, and cross-language reuse. "Fast" means that components developed with Visual FoxPro are extremely fast to retrieve and process data, and Visual FoxPro can quickly build strings. How fast, I want to data processing, the speed of access we've all been through it, string generation speed I have a data here to see, this is a Taiwanese ace to do the experiment--1 m of data written to the text, the result of VC + + 6.0 program with 3.5 seconds, VB 6.0 program with 11 seconds, Java 1.1.5 used 24 seconds, Visual FoxPro 6.0 for 7 seconds; "Reuse" refers to the visual FoxPro features oop; "Cross-language reuse" refers to objects that are written by visual FoxPro to become COM, COM + object components, This allows you to use it in other languages.

Do not assume that visual FoxPro is a "low-end product" and that it is a "high-end tool", whether from a database (DBF Base) quality or a development environment to evaluate visual FoxPro.

Many people think that Visual FoxPro can only be used to develop a single user system or a small network system of File server architecture--This is a fallacy--this ignorance of the speech in many speak C/s, three-tier architecture of the books are (especially some VB, PB, Delphi database Programming Books). I can be very responsible to tell you that you can use Visual FoxPro to develop C/s structure of the system. Here said the C/s structure is absolutely authentic, not with what f/s framework in fooling everyone. In the C/s framework, we often choose Visual FoxPro as the Client development tool, with Oracle, SQL Server and other network databases in the background, using the Visual FoxPro built-in remote view and SPT technology, so that the problem can be solved perfectly. This cannot be expanded in detail, except to specifically describe the role of the Visual FoxPro local engine in development. The local engine of Visual FoxPro is particularly powerful (as we have said in the previous millions records), we can design the system is very simple to combine remote data and local data, very simple, very effective control of network data flow, improve system efficiency (I have seen a lot of VB, Delphi, PB Books, they rarely in how to control the network data flow, improve the efficiency of the system discussion, I do not know is dismissive, or other reasons.

I think the local engine of Visual FoxPro has at least three great uses under the C/S architecture. One: local storage of data that is not constantly changing. The relationship between postcode and region in China is relatively stable data, and the amount of data is not too small, I think there are thousands of records (I did not examine the details), we store this information on the client computer, you can use the postal code and its related information from the local data, This will enable high system efficiency at the same time Save network resources (this is the important principle of C/s development), only when the postal code changes in the server on the unified update, download the update client data. If you implement the same functionality with other software, it's definitely more cumbersome than visual FoxPro and definitely less effective than visual FoxPro, because the visual FoxPro data engine directly supports remote data-reading, which blends local and remote data well; second: Offline packets. The unit is always someone on business, in tens of thousands of miles outside can take a notebook for customers to send orders, and customers sign contracts, like in their own office? When he comes back to the company, just connect the laptop to the server and send updates. The offline view of Visual FoxPro is an economical and efficient security solution (you can, of course, use remote dial-in or build a Web site that these Visual FoxPro may do). In fact, offline packets also have an important function: When the downloaded data is large (unless you have to do so to design the system), in which case the offline view allows the dataset to be automatically transformed into a physical table, taking full advantage of the high speed and flexibility of Visual FoxPro, and then updating the back-end data source after the completion of the connection- Everything is simple. I think: Offline View is definitely a Visual FoxPro in the C/s system of a selling point, although ADO also support similar things, but certainly less efficient than Visual FoxPro; three: Data driven. Whether you know that most of the file formats in Visual FoxPro are DBF files, such as DBC, SCX, FRx, and so on, they can be driven by the local engine of Visual FoxPro to accomplish complex tasks. In the design of C/s structure, if you want to store user settings, custom file format, with the Visual FoxPro local engine help is absolutely simpler than other software, because you are using the method, but it is simple and efficient.

Visual FoxPro Development of C/s system, the most distinctive feature is the remote data manipulation is achieved through the local database, remote View, connection as the local database objects are managed, the perfect interface between local data and remote data. This approach to establishing remote data logic on the client side is similar to the latest ado.net!

In the three-tier architecture, Visual FoxPro can serve as an arbitrary layer of tasks, but I think the database part of medium and large system should be based on network database. The client interface is also possible with Visual FoxPro, but is generally limited to the enterprise, where IE is often used as the client interface on the Internet. Visual FoxPro is the most competent middle-tier development in the three-tier architecture, it is simple (development difficulty differs from ordinary Visual FoxPro projects), fast string generation, support COM technology, it supports (MTS) COM + technology, it supports XML (Visual FoxPro 7.0 provides 3 XML-related functions, it has a powerful local data engine, flexible data processing, and it supports the development of multithreaded service components.

Some people may ask: the asp+ scripting language can be used to develop web systems, why add a middle tier. Indeed, it is very incorrect to use scripting language to develop the entire system directly in the marketplace with more web-related books, and even the book says that the hardware is getting faster, so it doesn't matter how the scripting language is used to develop the whole system. The authors who say such things are usually those who do not actually develop Web application experience. Scripting languages such as VBScript are an explanatory language and run inefficiently, and they are only suitable as glue programs. The orthodox approach to developing web systems is to write application logic as COM, DCOM objects, and then drive/use these objects in a small number of scripting languages. This will make the system development work much larger, but it conforms to the most basic principle of developing any database application: Separating the application logic from the user interface. This will make the system easier to maintain-you can often change the glue program to alter the Web page, and when you apply a logical transformation you can change a logical object without worrying about messy and complex code. Furthermore, because Visual FoxPro is an efficient, flexible data-processing language, any business logic can be used to code, and you can gain dozens of times times as much as the asp+ scripting language and more robust execution.

The language of Visual FoxPro looks pretty hard.

People praise Visual FoxPro always compliment him for his ease of use, and I disagree with that view (I don't know where they stand). My point of view is "to be a decent visual FoxPro programmer", and my conclusion is that visual FoxPro as a development tool is not studious. This is not to say that Visual FoxPro syntax, concepts like C so complicated, but refers to: even simple applications, but also to master a lot of Visual FoxPro concepts, grammar, functions, may also be more in-depth understanding of oop--often let people touch the depth. For example, take the most important function of database system-query, Visual FoxPro on the "variety." I've counted, not counting "List, Browse," and other interactive commands, Visual FoxPro at least support 4 commands (FIND,SEEK,LOCATE,SELECT-SQL), 3 functions (Lookup (), Seek (), Indexseek () (Of course some of them have been eliminated) the keywords of these commands, the parameters of the function are numerous, some require indexes, some can be indexed but require optimization index ... And this in VB, Delphi is absolutely just two or three methods of things. From the above example if you only see the complexity of Visual FoxPro, then you are completely wrong: in VB, Delphi implementation of the principle of query function and Visual FoxPro should be the same, but they encapsulate a lot of links, and visual FoxPro A lot of things lower (certainly not as low as VC + +, but is already more difficult than using the language of the object) to show us, so the Visual FoxPro developers are often more than the use of other development tools developers more think, understand the essence of database development, Because the tools are forcing them to work in this direction ...

Using Visual FoxPro helps to improve programmer understanding of database concepts. Many problems that are not problematic in Visual FoxPro programmers are often the nightmare of programmers who use objects to process data. For example, in Visual FoxPro, data buffering, transaction processing are important concepts (in fact, to work must understand these things), in other development environments, the emphasis on easy and fast often ignore the basic concept of programmer training, the things that are either inefficient or old problems. Reading people understand: The basic concept, the basic theory is the lifeblood, this is the Visual FoxPro bring US benefits.

The interesting thing is that the Visual FoxPro complex, and his difficulty curve is the most stable in all languages-unlike in some languages, basic development is very easy, once the depth is very difficult. In Visual FoxPro, the difficulty of primary, intermediate, and advanced applications is very small-that is, familiar statements, Easy-to-understand functions. This advanced application of Visual FoxPro is not too difficult, the primary application is not very easy to the characteristics of beginners to be able to understand the beauty of it, which caused the Visual FoxPro of the unfriendly image;

At the same time, the difficulty of Visual FoxPro has brought a lot of benefits (I have talked a lot), Visual FoxPro than other languages in data processing faster, more flexible, more data processing methods, more complete. Imagine developing a data object with Visual FoxPro, we can use rich and colorful statements, functions, to achieve very complex, changeful function, in other languages to develop data objects, their functions can only be based on the existing data object function (this is called inheritance), the change is less, the function is weak. If you want to implement the xbase+sql of Visual FoxPro, you might want to use the underlying API--that's terrible!

Oop not only refers to the "object-oriented" development environment, but also a kind of development ideas, development technology, Visual FoxPro in the latter to do better.

We've talked about visual FoxPro fully supporting OOP, but what's interesting is that in data processing, Microsoft doesn't actually provide any ready-made objects (FFC is only visual FoxPro 6.0, and not packaged, adaptable), which I don't know is visual FoxPro's blessing is still a scourge. To say "good luck" would force programmers to master the not-so-simple technique (perhaps more appropriately "thinking"), rather than simply using objects. OOP is important for the development of the middle tier, because COM components must be based on OOP thinking, and it is necessary to master OOP techniques to develop such components; it makes Visual FoxPro less easy to learn and use (as far as I'm concerned, I really appreciate "using visual FoxPro should compile data-processing objects "This issue is also a long time after using Visual FoxPro." In fact, many of the people who attack Visual FoxPro do not have a deep understanding of the problem-they only feel that Visual FoxPro is not as easy to use as Delphi, PB, and VB, but they never want to develop data-processing objects, so they will die when they write COM components. Most of those "elites" do not know oop, they only understand the "point" operation Symbols-as if the use of objects is OOP, what are their qualifications to criticize us?

Is the Visual FoxPro interface really bad?

I think that the built-in controls that Microsoft has provided for us as a database system, plus more than 10 of ActiveX controls that come with it, are sufficient.

We discuss Visual FoxPro control should start from two aspects, the first is the appearance of the interface, then data processing, analysis is convenient. A lot of people really care about the previous question, I do not think--the control is not much, especially to beautify the interface of the control does not mean that Visual FoxPro can not develop a pleasing software, I feel that the professional degree of software interface, high-level aesthetic, the overall effect of the interface than individual effects of important light-billions, The actual effect can be better than light-billions. Take a look at foreign programs compiled with Visual FoxPro you will understand this; my dissatisfaction with Visual FoxPro is that data processing, analysis controls are incomplete, especially the lack of a batch of analysis controls. For example, there is no chart control that can be bundled with data, no table controls that can list bundled crosstab tables, no PivotTable controls that can bundle data ... In this issue, Visual FoxPro really should be to Delphi, Pb and other software learning, this is our vision of the future FoxPro expectations!

Visual FoxPro with Ole DB, ADO

ADO is the mainstream of Windows environment data access solution, those with object manipulation data language basically use ADO to realize data access, such as: VC + +, VB, Delphi. In the Visual FoxPro development environment, it seems that the shadow of ADO is not visible, does Visual FoxPro not support ADO? ADO is actually a set of COM objects, and Visual FoxPro supports COM, and of course it supports ADO.

I think: Visual FoxPro's support for ADO just stays at a lower level. This is not to say that Visual FoxPro limits what ADO functions (all functions can be used), but refers to: not convenient to use, unlike in VB, Delphi convenient. This inconvenience is mainly reflected in the ADO recordset cannot be bundled with the Visual FoxPro built-in controls. The reason for this is that Visual FoxPro does not know the recordset of ADO and can only read the records one by one, rather than recognizing the entire recordset at a draught. This data cannot be bundled, and it cannot directly use the Visual FoxPro powerful data processing capabilities of ADO (ADO is used to access data while processing data depends on client software).

Just as Visual FoxPro uses ODBC to connect to remote data sources, ADO talks to the data provider through OLE-DB. (By the Way:visual FoxPro 7 is the OLE-DB provider so that you can use ADO to access Visual FoxPro data in other development tools through authentic ole-db drivers.) ）

What can ADO bring to Visual FoxPro? The first thing to note is that ADO has nothing to do with the Visual FoxPro data Engine, and, to some extent, the presence of ADO provides a new way of remote data processing for Visual FoxPro.

1. ADO is the best solution for data collection delivery in multi-tier applications. If we use Visual FoxPro developed a middle-tier system, with VB to develop the user interface, when the middle tier to pass a cursor to VB client can not use Visual FoxPro cursor or DBF, because VB do not recognize them. Using the ADO recordset solves the problem because everyone knows him; visual FoxPro can only support XML with visual FoxPro 7 to compensate for the lack of visual FoxPro local engine delivery of the dataset in the application.

2. ADO can access a database of non relational types. ADO is the chief proprietor of Microsoft's Universal Data Access architecture, and it can access data from non relational databases such as Excel. Visual FoxPro, which accesses remote data through ODBC, has no such capability. But I was disappointed when I used ADO to access Excel, because the connection had to be exclusive, so this kind of functionality brought us only a limited amount of help!

3. ADO can make up for the deficiencies of Visual FoxPro in remote data access. For example, Visual FoxPro does not recognize data types such as ntext, NVarchar, and nchar in SQL Server, but ADO can.

Using ADO in Visual FoxPro has the following drawbacks:

1. Visual FoxPro can only identify the ADO recordset by COM, not read and write to it like a table, and there are two problems: the Recordset cannot be bundled with the Visual FoxPro built-in controls; FoxPro powerful data processing capabilities (ADO is used to access data and processing data depends on client software).

2. The Visual FoxPro uses code to implement all of the functionality of ADO, but it has a large amount of code and trouble writing.

To treat the above deficiencies the visual FoxPro development team released a component called VFPCOM.DLL shortly after the launch of Visual FoxPro 6, which can be used to partially resolve the ADO recordset and visual FoxPro cursor transformations and the binding of ADO events, Visual FoxPro is built in to support COM event bindings. In the first edition of this article, I had the hope that "Visual FoxPro more efficient support ADO." Now my view has changed a little, I think in visual FoxPro processing data, whether local, or remote data, whatever the architecture of the system, the best solution to recognize the built-in data engine, rather than the current popular ADO, now Visual FoxPro has enough support for ADO!

What is the advantage of the Visual FoxPro data engine compared to ADO?

1. Visual FoxPro Data Engine system resource consumption is small, ADO is after all, COM components to spend more resources.

2. As a system-sharing component, using ADO may generate an ADO version problem in different application systems, like the ActiveX control versioning problem we often encounter.

3. ADO is just a data access component, it has no data processing function, to process data must use client applications, such as VB, Delphi. The Visual FoxPro data engine supports data access and processing at the same time, and I have repeatedly emphasized the great capabilities of Visual FoxPro in both areas;

4. ADO does not have a local database as a strong support, there is a need to temporarily store remote data in physical files ADO is definitely not as visual FoxPro. The Visual FoxPro database is the best in the desktop database, and remote data staging is not only convenient but also scalable.

5. After using ADO to get data from a data source, it is cumbersome to group, query, and summarize data collections, but Visual FoxPro supports data processing for cursor, and we can use most xbase languages (except for table maintenance languages like Zap and pack) , you can also execute SQL statements against cursor--a powerful power that no ADO can match.

When developing stand-alone programs, do not use ADO, so neither development efficiency nor operational efficiency; We should choose Visual FoxPro SPT and remote View when developing C/s system, they can perfectly solve the problem (there are many successful experiences), There is no need to use ADO roamed, in the middle-tier development, you can consider using ADO, we are very efficient in this case to use ADO development efficiency is very high, because at this time all the code should be written in one sentence, one sentence (same as in other development environment), Visual FoxPro's syntax is simply coupled with the extremely powerful IntelliSense features of Visual FoxPro 7 (really fast and customizable by the user), and maybe we'll take advantage of it.

Although ADO and visual FoxPro are completely unrelated to the system, they have a common mother--foxpro development team, the original ADO cursor set (Cursor Engine) was developed by them. If you understand both ADO and visual FoxPro, you'll find that many of the ideas in ADO are exactly the same as visual FoxPro ... I always use this allusion to convince those who do not believe in Visual FoxPro: the most popular ADO cursor set is written by the FoxPro development team, and there is no reason to suspect that the Visual FoxPro data Engine-it is the best in the world!

Visual FoxPro is a long history of products, many users from Foxbase to FoxPro to Visual FoxPro, this step by step. The accumulation of history, the burden of history is also heavy-many programmers tend to grasp the old products and forget to delve into the new features, this is a sad.

I met many people who use Visual FoxPro, also called "Query Design" as "rqbe", friend that is the concept of the DOS era.

Many people do not delve into visual FoxPro, just see a feature from other tools and imagine that visual FoxPro doesn't support it. Delphi specifically pointed out that it has heterogeneous data-related capabilities, such as: The parent table is SQL Server data, the child table is Access data, requires the establishment of association, implementation of "a multiple relationship." The Delphi requirement uses a special SQL syntax to implement this feature. The Visual FoxPro document doesn't seem to specifically describe this feature, does it? If you have a deep understanding of the remote view of Visual FoxPro and the use of cursor, the answer is easy to get. In fact, with Visual FoxPro can be more direct, simple implementation of the implementation: build two "connection", two "remote View", the child table index, Set relation to,set skip to ...

In turn, the functionality that Visual FoxPro can implement, Delphi's BDE (the local engine of Delphi) does not: The Visual FoxPro Remote view can set the result set to be updatable after multiple tables are associated. and update the background data automatically after the data changes are generated by the update clause. For example, to establish a connection to the pubs database in SQL Server, create a new remote view as:

CREATE SQL View TEST view REMOTE CONNECTION CONNECTION1 as SELECT publishers.pub_id, Publishers.pub_name, titles.title_id, Titles.title, Titles.price, authors.au_id, Authors.au_lname, Authors.au_fname, Authors.phone, Authors.address from Dbo.publishers Publishers, dbo.titles titles, Dbo.titleauthor titleauthor, dbo.authors authors WHERE titles.pub_id = Publ ishers.pub_id and titleauthor.title_id = titles.title_id and authors.au_id = titleauthor.au_id ORDER by Publishers.pub_id

This is the relationship between the four tables, which is a more complex SQL statement. Don't worry, it's all in Visual FoxPro just click a few times with the mouse in the View Designer. When you add, delete, modify, and send updates to the view, Visual FoxPro is intelligently analyzed, resulting in an update that updates the changes to several tables in the backend. And the Delphi BDE can only have this function to the Xbase data source, to other data sources have no this feature. Visual FoxPro can support all ODBC data sources (as long as the data source itself supports), such as Oracle, SQL server,access ... Of course, in Delphi 5.X can make up this flaw through ADO, but Visual FoxPro also support ADO. The Visual FoxPro programmer should have the confidence that Visual FoxPro provides us with the best local engine!

Ancient cloud: To good things, its prerequisite. So we do not accuse the tool how, how, look at their own use well no!