The definition of the word paradox seems to fit the software rendition well. A paradox is something that appears to contradict itself or be contrary to common sense but might be true. The name applies well to the Paradox database development environment because it is very powerful, yet easy to learn and use. With Paradox, you can quickly prototype an application for a client and then turn the prototype into the full application; this is known as rapid application development (RAD). Paradox brings RAD development to a new height of simplicity and power.
ObjectPAL stands for Object Paradox Application Language. The acronym portion of the name (PAL) comes from the DOS version of Paradox. The term Object was added to the name because ObjectPAL is an object-based event-driven programming environment that is much more advanced then its PAL predecessor. What does this mean to you? It means you get to work with a development environment that uses the analogy of objects to represent programming elements such as windows, buttons, fields, and bitmaps. Why is this so important? It is important because humans perceive everything in life as objects--for example, cars, houses, trees, dogs, and cats. Furthermore, we naturally break down each of these objects into other objects. For example, a car object is made up of other objects, including tires, frame, engine, and steering wheel. This makes using a car a relatively simple experience. We do not need to know that a carburetor is an object contained within an engine. We don't even have to know that an engine is an object contained within a car. We simply have to know how to use the interface the designers of the car gave us to work with. We have to know how to use the door, key, steering wheel, gas, and brakes. We don't need to know the specifics of how the engine generates energy that is transferred to the wheels. The concept of just using the interface to an object and not knowing the details inside is called the black box component model. In other words, a designer creates something (an object) and gives the users of the object an interface. The term black box refers to not being able to see what is within the box. In Paradox, you do not need to concern yourself with the details of what happens when you push a button--you simply attach code to the pushButton event of a button (the interface given to us by the designers of Paradox). This is the basis for object-based and object-oriented programming--hot topics these days.
Before we continue our journey into object-based programming and ObjectPAL, you need to review a few concepts. The first few chapters deal with issues such as planning, table design, and interactive form design. These chapters also discuss interactive issues that an ObjectPAL programmer needs to keep in mind. The rest of this chapter gives you an overview of the design and development process. It begins with a discussion of why you should use Paradox. Then, it moves into a discussion of types of applications and which types of applications Paradox is suitable for, then follows by discussing how to design and develop a good database application.
Why Should You Use Paradox?
A database is an organized collection of information. For Paradox table users, this meaning is stretched to mean a set of related tables (usually in the same directory). Paradox allows you to access Paradox tables and other types of databases, and is much more than a simple database program. Paradox has made complex databases accessible to the average user. In my opinion, Paradox has three levels of usability: easy database access, complex database access, and custom database application development. Although this book touches on the first two levels of usability, it is primarily concerned with the third: custom database application development.
Easy database access enables you to create simple database tables and to enter and browse through data quickly with the traditional table window or a more flexible form. In addition, Paradox delivers easy database access by providing you with a plethora of experts available in Paradox. These Corel Paradox Experts allow non-programmers and programmers to easily accomplish tasks like creating a complete employee records database application or documenting an existing application.
Complex database access enables you to ask complex questions about your data. In Paradox, you can set a filter in a form or ask a question of your data with a query. After you find the answer, you can use crosstabs, graphs, and reports to communicate the answer to your users.
Custom database application development includes bringing all the elements that display data--such as table views, forms, and reports--into a cohesive presentation. The application development side of Paradox brings a friendly user interface to the end user and a powerful language called ObjectPAL to the programmer. These elements together enable you to better control the application environment.
Paradox is the best tool on the market for delivering these three levels of usability. This should be a major consideration when deciding what tool to develop a custom database application with for yourself or a client. Deliver a custom database application in Paradox and you deliver the most powerful data manipulation environment available with a balance of easy and complex database access and custom database application development.
Types of Tables--Which Type to Use
Paradox is capable of using both local tables (such as Paradox or dBASE) and remote tables (such as Oracle and Sybase). This means that, as a Paradox or dBASE developer, you can read and write Paradox and dBASE tables and indexes without importing them. This is important. Some developers get confused about this issue and ask how to convert a dBASE table to a Paradox table or vice versa. The answer is, you don't. Paradox is a front end to any type of data that the database engine can access. If you need to copy the data from dBASE to Paradox format, or vice versa, then simply copy the table giving it a new extension (for example .DBF to .DB). The database engine takes care of the details.
In addition to local table structures such as Paradox and dBASE, you can use any of the SQL servers supported by the database engine. This includes InterBase, Oracle, Sybase, MS-SQL, DB/2, and Informix. Also, the database engine is ODBC compliant. This means that you can use almost any ODBC driver to connect to almost anything, including text files, Btrieve databases, Excel spreadsheets, and Access databases.
Types of Applications
There are many types of applications, but because Paradox is a database management system (DBMS), it's best suited for developing custom database applications. This doesn't mean that custom database applications are the only type of application you can develop. In fact, you can develop many types of applications with Paradox. Table 1-1 discusses how well suited Paradox is for developing various types of applications.
Category
Suitability
Comments
Manager system
Sometimes yes
Suitable when the applications are written in Paradox.
Business data
Yes
Paradox's strong point.
Informational
Yes
Paradox's strong point.
Kiosk
Yes
Paradox's strong point.
Educational
Usually yes
Educational software often uses tables.
Desk accessory
Sometimes yes
Suitable only when a Paradox application is used.
Games
No
A few interesting games can be created, however.
Prototype
Yes
Prototyping applications in Paradox is very fast.
General utility
No
The exception is a database utility.
Graphic
No
Although Paradox has good graphics capability, it is not well suited to develop a graphic program.
Table 1: Types of Applications and Paradox
Usually, choosing a tool is easy. When you are asked to do a certain project or when you get an inspiration to develop an application, usually you know what tool you should use. Clearly, Paradox isn't the best tool for every category of software. For example, you probably would not wish to write a file utility with it. If a project involves extensive amounts of data, Paradox will likely be well suited for the job. ObjectPAL is the powerful backbone of Paradox and therefore can be the backbone of a large DBMS. Paradox also is useful for prototyping an application that you plan to write in Delphi or C++Builder. Prototyping is the process of application development in which small parts or the general structure of an application are designed and tested. These models are used as the basis for building the finished system. If you are going to develop applications, it is important to know what tool--or development environment--to use.
Where to See Various Types of Paradox Applications
Before jumping into the formal discussion, you should see what Paradox is capable of. Sometimes it's nice to see what a product can do. As they say, "Seeing is believing." Knowing what a product can do is half the battle. If you haven't done so already, take some time now to study the applications that shipped with Paradox and run the application experts, too. If you have Internet access, you can view many completed Paradox applications with source code at the following URL:
This Internet page is the support page for this book. It is part of the Paradox Online forum, which is hosted by Mike Prestwood. The Paradox Online forum is one of many forums contained on PrestoNet (a FREE worldwide Internet environment).
Multiprogrammer Developing
When developing a large application, you will need to program in a team environment. Programming in a team environment is dramatically different than programming by yourself.
Divide and Conquer
The most dramatic part of getting used to programming in a multiprogrammer environment is getting used to the fact that you are not in charge of all the code. The best way to create a successful multi-programmer environment is to divide the responsibility of the program among all the programmers, with no overlapping assignments. This way, you establish pride of ownership, and each programmer can do his or her best to make modules complete and bug-free.
Establishing Programmer Roles
Depending on the size of the team created, you can have any of the following roles: grunt programmer, lead programmer, architect, project leader, QA tester, unit tester, business analyst, user interface expert, and so on. The role a particular programmer will fill depends on his or her programming skills, how well he or she gets along with others, his or her leadership capabilities, and finally his or her knowledge of the requirements, design specification, and database.
Note: Many Paradox developers act as the analyst, programmer, tester, and project manager--a single-person team. If you are a single-person team, this section still applies to you and you can still benefit from the information by adapting it to your environment. For example, you may be the only developer, but perhaps you can find someone on the business side that can do the testing or project management.
Development Roles
Whether you are an individual developer or part of a team, you need to fully understand the various roles individuals play during the software development life cycle. No matter how many individuals are involved with a large project, the development team usually consists of a project manager, a business analyst, a system architect, and one or more lead programmers. Even in multiprogrammer development teams, an individual may commonly fill more than one role. If you are an individual developer, you fill all the development team roles.
Project Manager
The project manager is the glue that keeps the project moving. He or she may be a technical or nontechnical project manager. Although it is not usually recommended, the technical project manager often doubles as the system architect. In either case, the project manager is responsible for coordinating efforts among the user community and the development team. Usually, the programmers, analysts, and quality assurance personnel report directly to the project manager and the project manager reports indirectly to the executive sponsor.
Business Analyst
The business analyst can work either for the user community or the development team. This person coordinates, gathers, refines, defines, and prioritizes the various user requirements. This role is often filled by a lead programmer or the system architect.
Database Administrator
The database administrator (DBA) takes the business requirements and develops the database specification. The database specification contains all the table names, field definitions, data restrictions, trigger definitions, and stored procedure definitions. The DBA is also responsible for creating and modifying the database. On smaller projects, this role is often filled by the lead programmer or system architect.
System Architect
The system architect takes the business requirements and the database specification and develops the software specification at the highest level. The system architect is also responsible for selecting the tools used for development.
Lead Programmer
The lead programmer (often the same person as the system architect) works with the system architect to flush out the details of the software specification. The lead programmer understands the big picture; he or she understands the goals and high-level architecture of the application.
Programmer
A regular programmer works with the lead programmer or system architect to code specific tasks. This level programmer may not understand the whole picture. In fact, this position is usually told very specifically what and how to code.
User Community
As a software developer, you need to identify the key players in the user community for whom you are developing an application. Identify who will be using the software and get them involved in the design and testing of the software while it is being developed.
EXECUTIVE SPONSOR
The executive sponsor is responsible for final decisions. Often, conflicts may arise among the development participants, and only the executive sponsor can resolve them. Also, the executive sponsor signs off on requirements, accepts the application, and usually pays for the application.
DEVELOPMENT PARTICIPANT
A development participant is the person who at first deals with the business analyst and system architect to define and refine requirements. If you are using the rapid application development (RAD) process, the development participants also participate during development with the programmers, approving the features as they are implemented. Finally, the development participants are involved at the end of the process in testing (beta testing).
Versioning Software
Versioning software enables you to keep track of various versions of the same file. This way, you can roll back to any version of the file that you have checked into the versioning software. Versioning software tracks and organizes all revisions of all files associated with a project. It also enables developers in a multiprogrammer environment to lock files being developed to safeguard against duplicate development.
One such commercial versioning software program I recommend is PVCS. PVCS (Project Version Control System) is a third-party software program created to track the revisions of files associated with a project. It has become one of the standard versioning software applications in the industry.
Developing Large Applications
It's important to understand the elements of ObjectPAL, but if you don't keep the big picture in mind, the end product suffers. Gaining the ability to develop large applications as an individual or as a small or large development shop requires that you set up a process for developing software and then document it. Many methodologies for developing software exist. This section will introduce you to what is needed to develop large applications and will help developers of all levels create better, more elegant applications. Its intent is to start you thinking about the big picture and to spark your interest in the software life cycle. Whether you are an individual or part of a large development shop, I hope you will go out and pick up a few books on the software life cycle and software development methodologies.
Note: To see a complete software development methodology in use by Prestwood Software & Consulting (PSC), log on to the Internet and go to http://www.prestwood.net/psdm. There, you will find Prestwood Software Development Methodology. This is the methodology used by PSC to develop software for companies, and you can use it as a starting point to developing your own software development methodology.
The Software Development Cycle
The software development cycle, also known as full cycle development, is the process of developing a software application. Without a set and documented process, the end application is likely to be buggy, not meet the users' needs, and take too long to develop.
The purpose of this section is to define the software development cycle as it affects the development team and the user community. The cycle itself is composed of a series of steps punctuated with milestones. These steps lead from the analysis of a new application to its development, testing, and eventual deployment. Each step is defined in detail.
An approximate duration for each step, if applicable, is given for example only; the estimation assumes five developers, one business analyst, one quality assurance tester, and a medium-sized application. The estimates are included only for reference. The actual duration will depend on many factors, including quality of business requirements analysis, complexity of the requirements, talent pool of programmers, and testing plan.
Remember that the application development cycle is a developing process that is revised on an ongoing basis. You should not consider it to be set in stone, but it should act as a guideline; you should use it in accordance with the needs of the current cycle.
Waterfall Versus RAD
With the waterfall approach to developing software, one phase of the development cycle follows the other and the user is involved only at the beginning during the requirements gathering phase and at the end during the acceptance phase. The requirements gathering in the waterfall approach is critical and unless it is 100 percent perfect, the project will fall short. With the rapid application development (RAD) approach to developing software, the user is heavily involved throughout the development process. In true RAD development, software is often very focused on a specific task. If you need to create several applications for a single client, then true RAD can lead to several independent applications that do not communicate and sometimes overlap in functionality.
My preference is for a modified RAD approach to development. In a modified RAD approach, emphasis is placed on thoroughly gathering requirements and involving the user in both the coding and testing phase of development to continuously validate that the product being developed is the product the client wants.
Overview of the Life Cycle of a New Application
The following is a list of the steps in the application development cycle:
Feasibility study
Requirements gathering
Requirements freeze
Requirements sign-off
Design session
Database specification (logical design)
Software specification (logical design)
Database freeze (logical DB specification implementation)
Except for this chapter, this book is primarily concerned with step 7 above (development). This step involves the coding and debugging phases of the software development cycle. Occasionally I digress into another area when the subject is something that a programmer needs to know to be more productive, or is something that helps you understand how Paradox and ObjectPAL fit into the software development life cycle.
Gathering Requirements
Requirements are collected by the business analysts, system architect, and development participants. The average duration needed to gather requirements is directly proportional to the size of the application. Five days is usually sufficient for a small- to medium-sized application. New requirements for the application are gathered until the requirements freeze. The business analyst also needs to identify the requirements critical for the application to be accepted by the executive sponsor at an acceptance meeting. The executive sponsor is the person identified on the business side that has final decision authority on all development issues, and is often the person controlling the budget.
The requirements report should be broken down into logical categories--for example, business rules, validations, data input, data output, reports, external hardware and software requirements, user expected response times, security, and, finally, open issues. The project manager should create a set of questions to weigh the quality of the business requirements. Examples include "Are all the report formats specified?" "Are all the tasks the user wants to accomplish specified?" "Is success clearly identified?" "Are any of the programmers uneasy about any of the requirements?" and so on.
DEALING WITH BUSINESS RULES
Creating a database isn't just about creating tables and linking them. It is also about implementing business rules on the data. For example, in an invoicing system, you need to multiply quantity times price to get each line total on an invoice. Then, you sum up the line total and multiply it by the local tax rate (and perhaps add shipping costs). These are all business rules. Another less obvious business rule might be to start charging interest on invoices that still have a balance due after 30 days. When gathering requirements, remember to ask your client about all the business rules and incorporate as many as appropriate into the application.
REVIEWING REQUIREMENTS
The requirements freeze represents the point at which new requirements are moved to the next development cycle. Any new requirement after this point must be approved by the project manager if it is to be included in the current development cycle. The project manager is responsible for keeping the scope of the project within the boundaries agreed upon between him or her and the executive sponsor.
SIGNING OFF REQUIREMENTS
After you have defined the user requirements, you should have the executive sponsor sign off on the requirements list.
Tip: When you're finishing an application for a client, nothing is more frustrating than the client telling you that the application is all wrong. Do yourself a favor: During or shortly after the planning stage, be sure to echo to the client what you heard him or her say. Also consider putting your general plan in writing and have both you and your client sign it. This approach makes you a more professional consultant.
Deliverable: Functional Requirements Document
From the time your client agrees to hire you to create an application to the time you actually deliver the application can be a long time--in some cases, more than a year. Keeping your client in the loop and up to date is important. An excellent way to update your client is to have regularly scheduled status meetings. Another way is to give the client status reports as you reach each milestone. The functional requirements document is great milestone and should be delivered to the client for review.
Deliverable: User Interface Requirements Document
The user interface requirements document represents how the application will look and feel. Although you have already received input from the user, a good next step is to prototype the application and demonstrate the prototype to the users with the goal of either having the users approve it or refine it.
Planning
To put it simply, involve every member of the team. Any programmer with any experience will tell you that planning an application is just as important as getting started on it. In other words, the first step in designing a database application is to sit down, take some time, and think through the process. Each assigned developer should estimate the time requirements for each task assigned to them (this estimation phase could take an additional day or two). The project manager then compiles all the information into a project plan. Each developer is also responsible for creating a test scenario for any requirements he or she implements.
DESIGNING THE DATABASE AND SOFTWARE
In a session away from the user community, the development team creates the database and software specifications. The software specification lead is the system architect, and the database specification lead is the DBA (this is often the same person). Gather all the data components and categorize them into tables. After you gather the business rules and data components, you need to decide on table structures. Whether you're developing a complete invoicing system or an application that just keeps track of phone numbers, planning your table structures correctly can save you hours of work later. Although Paradox makes it easy to restructure your tables later, you can never recover the time and frustration wasted because of poorly designed table structures. If you have all the correct participants and the requirements analysis is good, you can usually nail down the initial database in a day or two.
Develop your tables with your primary keys in mind. (Chapter 2 discusses this point further.) Increasing or decreasing the length of your fields is easy in Paradox, so keep in mind the minimum size needed as you develop your field lengths. A little careful planning can save you hours of backtracking later.
DELIVERABLE: SOFTWARE SPECIFICATION
The software specification document represents an interpretation of the functional requirements document and the user interface requirements document. This document represents how you are going to implement the software features. It is a detailed description of the required characteristics of the application.
DELIVERABLE: DATABASE SPECIFICATION
The database design is also based on the requirements. Do not hide the database you are creating from your client. Show it to him or her. The Database Specification Document is a good place to do that.
DELIVERABLE: TEST PLAN
The user should be involved with creating the test plan for the software. That way, the software will work the way the users want it to.
Freezing the Database
Freezing the database is the milestone where the DBA implements the database specification. This is an important milestone to reach on time because, in general, very little coding can occur until the database is stable.
Coding Software
You are probably most familiar with the coding phase of the software development life cycle. This book focuses on this phase, which includes module coding, programmer integration testing, resolution of existing bugs, and optimization of code. This phase can take anywhere from three to eight weeks on a medium-sized application.
Programmers develop new features as described in the development specification into the application. The business analysts and the development participants are enlisted by the programmers to verify that the new features are developed. This step ensures correctness. This point is also a good time to involve your quality assurance department (testers). The quality assurance team can test the software against both the user requirements and the software specification.
FREEZING THE USER INTERFACE
The user interface freeze (UI freeze) is necessary so that the developer(s) developing the help file and manual can start finalizing the documentation on how to use the application. This milestone is also helpful for keeping the development process moving because it forces the decision makers (the developers, analysts, and business participants) to decide on the look and feel of the application and specific menu and window designs.
DEVELOPING THE HELP FILE AND MANUAL
Once the UI freeze occurs, you can dedicate some resources to documenting how the user is going to use the application. If you are a single developer, this step obviously cannot start until after the development is done. In a single-developer environment, this is likely to delay the deployment of the application.
FREEZING FEATURES
Put simply, no new features. This freeze date is the final deadline for functional changes to the application. Debugging continues until deployment.
DEBUGGING SOFTWARE
In the final debugging phase, the development team thoroughly tests every feature and fixes any anomalies. These tests include unit and integration testing. In unit testing, each developer tests his or her own work. In integration testing, each developer tests his or her work integrated with everyone else's work, including the final help file.
Testing Software
In many shops, the project manager moves control of the software from the programmers to the quality assurance group, along with the user requirements and software manual. The quality assurance team conducts initial acceptance testing to verify that the application is stable enough to begin a formal test cycle. This development period is dedicated to resolving existing discrepancies in the application and verifying the application against the user requirements. (You learn more about testing later in this chapter.)
User Acceptance
The business analyst and project manager present the application to the executive sponsor. Usually, the system architect demonstrates the software for the executive sponsor. Development participants usually do not need to attend the acceptance meeting because they have seen the software all throughout the development cycle. At this point, you can have the executive sponsor sign an acceptance contract that lists the critical features needed for acceptance of the software gathered in the first steps.
Deploying the Application
Deploying the application is, of course, the final step in developing an application. Do yourself and your client a favor and take some time to develop a fallback plan in the event you deploy the software and something goes wrong. If, for example, the company for which you are developing software has an existing software application, create a backup plan to return to it in case the software you are developing fails for any reason. If your clients have a manual procedure, make sure that they are prepared to return to it if needed.
Conventions
You should develop or adopt a coding convention. Perhaps consider developing or adopting both a general coding convention and an ObjectPAL-specific coding convention. For more information on coding conventions, refer to Appendix A.
Documenting Your Application
You can employ many methodologies for documenting a large software project. The following sections describe some of the documentation I use when creating large applications. Should you create all these documents for every project? No. The size and importance of the project determines how much documentation is called for.
Business Proposal
Sometimes known as the project charter, the business proposal contains the general information about your company, values, mission, and very high-level information about the project or projects you are going to deliver for the client.
Project Plan
The project plan contains the detail steps needed to complete the project, who is assigned to each task, how much each task costs to complete, and more. One popular tool for creating such a plan today is Microsoft Project. Figure 1-1 shows a Gantt chart of a typical medium-size custom database business application.
Figure 1: Microsoft Project showing a project plan in a Gantt chart view
Creating a Software Developer's Guide
A software developer's guide is a manual written by programmers for programmers. Its intention is to aid the coding and debugging of the application. In addition, you can use this guide to document programmer procedures such as how to use whatever versioning software you use and overall design considerations. Additionally, the software developer's guide is a good place to put miscellaneous notes that do not belong in any other document.
The software developer's guide often includes a section titled "Application Style Guide," which documents how the application should look and feel. As you will learn in Chapter 3, you should be consistent in how you design software. In a multiprogrammer environment, consistency is difficult to accomplish without a style guide. Either as part of the software developer's guide or separately, you should document the user interface of your application. This is especially important on large applications.
Using Paradox's Visual Database Designer
Paradox comes with a very handy tool, the Visual Database Designer (select Tools | Data Model Designer). With it, you can easily document local and remote databases. Figure 1-2 shows a data model of an invoicing system using the sample tables that ship with Paradox. You can even print the data model and put it in a common location accessible by all programmers.
Figure 2: The data model from an invoicing system
Creating a CRUD Matrix
CRUD
is an acronym that stands for create, read, update, and delete. A CRUD matrix documents what objects (forms, reports, libraries, and scripts) access what data elements in a database. It can help you test your software on large projects and is critical for maintaining a large application. If you make changes in one form or script, a CRUD matrix can tell you what other forms, libraries, scripts, and reports will need to be tested.
Testing
The alpha test cycle is the preliminary testing of a new product in which research and development are still in progress. The beta test is a stage in product testing in which testing is done with actual users in the users' environment. The following sections offer some hints and tips on testing your completed application.
Creating Test Data
Test data is especially created to test the operation of a given program. Usually, one or more hand-calculated results or otherwise known results are associated with test data so that the program under test may be validated. Also, data known to be invalid is used as test data.
Developing Test Scenarios
Develop test scenarios with your users so that you can standardize your tests. After you develop a set of standard tests, you can often automate the tests with automated testing software. This type of software is similar to the Windows recorder provided with Windows 3.0 and 3.1. Automated testing software can record mouse movements and keyboard presses.
Unit Testing
Unit testing
is the testing of a unit. A unit is a recognized section of a program--for example, a form or group of forms. The programmer who programmed the unit usually performs the unit testing.
Integration Testing
After all programmers are done writing their modules, the modules need to be integrated and tested. This phase of testing tests how well all the units and modules fit together. On large projects, you often go through a build process where you bring all the application objects together for testing. This can include all the Paradox objects from the various programmers and a new database. This is where versioning software such as Intersolv's PVCS comes in handy because it can keep track of all the latest objects ready for the build process while the programmers continue coding.
Regression Testing
Regression tests are performed on a previously verified program whenever it is extended or corrected. In other words, you test all the bugs that were fixed. This step guarantees that previously identified bugs do not reappear in the program.
Testing the Boundaries
Testing boundaries
is also known as stress testing. Stress testing is ensuring through trial operations that the program or system will continue to perform reliably in spite of data inaccuracies and extraordinary data volumes. Try your application with very large tables and empty tables. Run it on systems with the least amount of memory Paradox will run on--4MB. Log any errors you come across for final testing. Finally, play a game of "what if." For example,
What if the user uses a corrupt table?
What if the table gets moved or deleted?
What if the user starts up using the wrong working directory?
Try to add your own questions to this list.
Tip: If you are a single developer, try to find someone else to exercise your program. As the programmer, you have certain ideas of how a user will use your application. These ideas probably apply to about half the users.
Running Every Feature Three Times
Test each feature three times. Sometimes errors in logic don't show up until the second or even the third time through a sequence of events.
Protecting Your Application
Protecting your application means that users can't edit your application, even if they own Paradox. In addition, you want to restrict the users' movements through your application. You don't want users to exit without your permission. Also, you don't want users to be able to alter your applications. To protect your applications, you need to do only two things: password-protect your data tables and deliver your forms, reports, libraries, and scripts.
Delivering Your Application
The final step in the development cycle is to deliver all the forms, scripts, libraries, and reports. In ObjectPAL, it's the process of compiling an object for a special Paradox-only dynamic link library.
Summary
In this chapter you learned that Paradox is a database development front end with an object-based programming language added to it called ObjectPAL. You need to use the right tool for every job. If you're building a game, a tool other than Paradox would be better suited. Paradox is best left to developing custom business database applications.
You also learned that to successfully develop a large application means that you must have a defined process in place. Paradox is just a part of the complete software development life cycle. This chapter touched on many parts of the full software development life cycle and introduced you to many of the basic concepts needed to start developing your own software development methodology by encouraging you to plan, document, and fully test the software you develop.
A particularly infinitive piece if composing it for us. I should say that it is directing us in the most ideal manner. U have perused best resume writing services reviews that are commendable and important enough on the whole respect. So attempt to be successful and assimilate such sort of data.
Begin in recent times through accepting obligation of your life and artwork on realistic dreams to reap that dream. It’s not constantly an clear aligners smooth road to journey on, however if you take one step at a time, you fast realize that the road is leading you to that freedom you dreamed about.
The hoverboard Ninebot Max Electric Kick Scooter is our pick for the best by and large Segway, with a ton of force and extraordinary speed for cruising anyplace. Another great alternative is the Segway Ninebot eKickScooter Zing E8 and E10, a reasonable bike made only for youngsters
We have all you require to plan for your IELTS test, including a wide assortment of free readiness materials. Begin getting ready for your IELTS test today.
IELTS Pakistan
Low Prices On Our�Automatic Driving Lessons�In�Halesowen�Give our friendly and professional�driving instruction�team a call now and learn everything that you need to know about getting your licence with us.�
Automatic driving lessons Halesowen
If you are pursuing a degree program in chemistry and finding it tough to submit your homework on time, Help In Homework is here with a solution. We offer top-quality chemistry assignment help to students who are unable to complete them on time because of their busy academic schedules. How does it work? It’s simple. Just get in touch through our website HelpInHomework.org and once you have discussed with our expert what and how much needs to be done, they take over from there and you can be assured that you have just relieved yourself from very big stress.
Servicemax.ae mission is to continually reassess our clients’ and customers’ needs, and to offer truly comprehensive solutions. which exceed their expectations in all ways. We aim to continually develop our network of national and international partnerships, creating ever more value for stakeholders and local communities alike. https://servicemax.ae/en/dubai/
<a href="https://www.superbudgetmovers.ae/">Super Budget Movers in Dubai Movers in Dubai Movers and Packers in Dubai Packers and Movers in Dubai Budget Movers in Dubai </a>
SSL Trainings is one of the online digital marketing training institutes in Lahore that is offering you the opportunity to learn new skills online at home. We are offering different courses on one platform and our highly experienced IT experts provide the best solutions. https://ssltraining.com/
Paradox
Print This
Tags:
KB Post: 
Article: 
Blog: 
