Q. I am an experienced DataEase developer (among other platforms) and have earned a living building applications for a long time. Your turnkey migration comes with a fixed-price. I don't know how you do this. My experience with fixed-price software projects is they simply can't be done profitably. How can you offer this? How do you stay in business?

A. First, the central vision of our architecture: If you step back from all of the dirty little implementation details like whose language, data engines, presentation wrapper or operating system you prefer, all business software applications are made up from the same handful of basic components (Data Structures, Data itself, Entry Forms, Navigation Menus, Reports, Procedures). No matter what platform has been used to construct and present the application to its users. To provide value, business software must present data to users, provide a structured, secure and controlled method to manage that data, transform that data into actionable information through reporting and analysis tools and provide a way to accept and push data from/to other systems and sub-systems. Those elements pretty much cover it.

As application platforms change, from DOS to Windows to an Internet browser, the construction details for those elements change, but requirements for their overall function remain very similar, if not identical. Forms must present and provide ways for users to search for and manage data. Reports must query and present the data in a useful fashion. Procedures must perform scripted manipulations of the data.

Understanding this basic thesis, the rest of our task is straightforward and predictable. First, the migration process we are performing is highly-repeatable. We have spent years developing and refining a software "machine" (the Application Migration Workbench or AMW) that does almost all of the "heavy lifting" for us. The AMW reads DataEase forms and writes target-platform forms, tables, and binding logic. It reads DataEase procedures and "writes" target-platform code that performs the same steps. The AMW does the same for menus, reports, etc.

On the output side, AMW re-uses the same tested software code templates that we have employed in dozens and dozens of migrations.

That means, while we don't know the specific amount of time and money any given form or procedure will consume to finish off, we do have a statistically-sound understanding of the average consumption of resources needed based on our prior work. We use that to provide the contract cost. We diligently monitor the actual vs. budgeted figures constantly to make sure we understand the cost of our process and to adjust prices as the AMW itself, the platforms and architectures change.

It also means that the target application we generate is consistent in structure from end-to-end. Something you just can't achieve performing a manual migration.

Second, the services we provide under our migration agreement are necessarily narrow in scope. We include the replication of forms, procedures, menus, etc on the target platform that will reasonably mimic the functional behavior of the original application. Realize that a DataEase application is really divided into two separate areas: DataEase itself and the things you or your programmmer created using DataEase. We stop short of attempting to replicate the entire DataEase operational environment key-for-key, step for step in the target platform. In other words, all target platforms we can migrate your application to supply techniques and methods of their own design for accomplishing tasks common to all business applications.

Q. Can you migrate our app to something other than Access

Sure. The AMW is now able to re-produce your DataEase applications for a fixed cost in a number of 'web' platforms including PHP/AJAX/MySQL, ASP.NET/ADO.NET, ASP/AJAX/ADO as well as WindowsForms. The cost is higher and the turnaround time is longer, but it works.

Contact us for details.

Q. How much programming help are we going to need after the conversion?

A. The answer depends on a number of factors. You can probably draw on your experience with your current DataEase application. Is your DataEase application being 'tweaked' pretty regularly or has it remained static for a long time? Who do you call, and how often, when you need help with your current application? Do you do it yourself? If so, are you as skillful programming in the target (e.g. Access) as you are in DataEase? How 'mission-critical' is your application and how many people use or depend on it?

The honest answers to those questions and others like them should lead you to a logical conclusion.

It always makes it easier if a client has available a local technical support resource who can provide a ready-response for the technical installation, training assistance and as a skilled conduit for our team to interact with. That does not mean we haven't performed many successful migrations for clients who had no local help at all; we have. It's just makes it easier all the way around when we have someone that speaks our language on the other end. That could be you or someone internal to your organization, as long as they are comfortable with Visual Basic. In other words, they should be, minimally comfortable programming VBA code behind forms and reports.

Although the Access application will look and feel very similar to your DataEase application, Access is different. It operates differently than DataEase and we've found it helps to have someone who understands the nuances on hand to help explain the hows and wherefores to the everyday users.

For large, transactional, high-volume, mission-critical applications, we recommend having at least one local Visual Basic programmer on-call simply because it will speed the implementation process to have a resource available to make the tweaks and format changes that often accompany the implementation an overhauled system. The reason we recommend Visual Basic and not just Access, is that we've found that most competent VB programmers have little trouble with the extra details of Access forms, reports and queries.

Of course, most organizations in which you would find such large applications typically have an IT staff on hand who will be tasked with implementation support. Again, VB/VBA programming experience is the core competency that will determine how effective they are.

A. All turnkey conversions include a second data conversion pass. In addition, all turnkey migration project installation kits include an unrestricted copy of our Table Migration Utility for your own use.

A. The application folder is the folder on your hard drive where all of your data for your DataEase application resides. The one file that is common to all DataEase applications is what is commonly known as the 'RDRR' file. The RDRR file is the internal catalog DataEase maintains of the objects used by a given application. Locate the RDRR and you have located the application directory.

The RDRR file follows the naming convention of:

"RDRR" & {a single-letter application identifier} & "AAA.DBM"

so:

RDRRAAAA.DBM
RDRRBAAA.DBM
RDRRFAAA.DBM

are all examples of RDRR files.

Generally, but not always, the single-letter identifier will be the first letter of the application name. So an application named: "Loan Origination System" would probably have an RDRR named:

RDRRLAAA.DBM

To find all your DataEase applications simply use Windows Explorer to search for files in the pattern of RDRR*.DBM. When you find the folder that contains your RDRR file, simply zip that folder and upload it using the form found at:

A. The easiest thing to do is to zip (compress) the entire application folder and then fill out the form you will find at:

A. We are pleased that you are looking at ConnectEase as a more robust alternative to LinkEase. We cannot guarantee that ConnectEase is bug free - what software is - but we do guarantee to respond quickly to any problems you encounter and will fix any ConnectEase failures to implement our advertised level of ODBC compliance.

Background

The DataEase file naming convention goes like this (you can view a lot of this in 'Application Maintenance','Database/Application Status':

All files follow the old DOS naming convention of 8 characters + a 3 character extension (i.e. XXXXMAAA.DBA):

• The first 4 characters (XXXX above) EQUALS the first four characters of the form or report name as it appears in the application. (i.e. a form called "A Customer File" would have a filename beginning with "acus")


• 5th character ('M' above) identifies the application within the containing folder. Usually the first character of the application name, but may be different if there are conflicts in the same folder.


• 6th-8th characters ('AAA' above) = a self-incrementing segment that differentiates file names with the same first four characters in the name.

FOLLOWED BY:

The file extensions (filetype).

• .DBM - data records


• .I?? - index files


• .DBA - form and table definition(ver 4.x)


• .TDF - table definition (ver 5.x)


• .CFM - form definition(ver 5.x)


• .DBR - procedure definition


• .CFE - form definition(ver 5.x)


• .TDE - pseudo-table definition (ver 5.x)


• .DBI - Import specification


• .DBS - System Form

So, to zip a whole application, you would choose all of the files in the folder for the application, i.e.

DIR ????B*.*

Selects all of the files in the app identified as 'B'. Or,

DIR TESTBAAA.*

Selects all files associated a form that begins with 'TEST'. May also include file associated with a report or an import specification whose name starts with 'TEST'.

To see form name:file name associations, you select Application Maintenance, Application Status from the main DataEase menu.

Stripping the Data

To send an application structure with no data, the easiest thing to do is to simply copy the entire application to a temporary folder( directory ), then delete all of the index files and DBM files, WITH THE EXCEPTION OF:

• RDRR?AAA.DBM


• REPO?AAA.DBM


• CONF?AAA.DBM


• USER?AAA.DBM


• CDFS?AAA.DBM


• MENU?AAA.DBM


• RELA?AAA.DBM

I think your quote is expensive. Convince me...

Q. I plugged the numbers from my application into your quote calculator and the total to provide a turnkey conversion is still several thousand dollars, which surprised me. I thought it would be cheaper than that. Don't you just put my application in a magic conversion machine and, voila!, you have an Access application? Why is this such a great deal?

Good question. And it needs to be answered on several fronts:

1. First, the AMU is not 'magic'. What it does is almost all of the 'heavy lifting' of a conversion. Tedious things, like constructing form and report layouts, data structure and conversion, overall application structure including menus, imports, exports, internal DataEase function replacements, etc. The AMU gives someone converting an application extreme leverage and a huge headstart. In fact, we performed a study where we compared converting a fairly complex form by hand with a form conversion aided by the AMU. The time required to generate a perfect replacement using the AMU was 23 minutes. The time required to generate a perfect replacement manually was a little over four hours (including fixing several hidden bugs introduced as a result of programming the form from scratch). That's over a 90% savings on straight conversion and, we would guess, there would be an even larger savings when compare to doing a rewrite from scratch. The best metaphor I can use is that the AMU is a machine like a backhoe or a bulldozer. It lets us can dig farther, faster, deeper with more precision than we could accomplish manually.
2. Peace of mind. Our turnkey service is a fixed-price, fixed timeframe service. That's pretty much unheard of in the software services world. How can we do that? Because the AMU engine and our process is repeatable and highly predictable. This means you can rest assured that your conversion needs will be satisfied in short order for a guaranteed price.
3. Many of our customers are IT staff that inherited the DataEase application when they arrived in their job and who have no familiarity with the application or DataEase. They assume that the DataEase application must be trivial (why? Beats us. Maybe the name has something to do with it.). Therefore, they tend to suffer from 'sticker shock' when they learn from our proposal that their 'little' DataEase application embodies 100 forms and 200 reports and will cost $6,000 or more and a few weeks to convert. What sometimes gets forgotten is that the same DataEase application probably represents tens or, even, hundreds of thousands of dollars of cumulative development cost (or more). Not to mention that the carrying cost and risk exposure of retaining the original application is escalating every day that passes.

Walk me through a typical turnkey conversion process. What happens, when?

1. We typically start with you providing a copy of your DataEase application to us.


2. We analyze the application and prepare a quotation which details the cost and estimated time requirement for the conversion.


3. We discuss any questions and concerns you may have.


4. We prepare and execute a contract. At that time a deposit is due. Upon receipt of the deposit, we assign resources and schedule the conversion start date. A project manager who is dedicated to overseeing and managing your relationship is assigned to your project.


5. On the start date, we begin the conversion process. We initially run our unique application conversion software that generates the raw Access application from your DataEase application.


6. Then, each form, menu and procedure is examined and adjusted as necessary to insure that it performs the same in Access as it did in DataEase.


7. Upon completion of the turnkeying step, we deliver the Access application back to you. We urge you to perform your own 'Application Review' process to insure that the new Access application is performing as your original DataEase application did. Payment is due at this time.


8. We provide you with access to an online resource for reporting any anomalies in your application which allows you to report and track any issues that you discover that need our attention.


9. We respond by correcting functional differences in the applications that you raise to us.

Q. What's the best way to save money on a conversion?

If you do not have the familarity or expertise to analyze the application, we offer a fixed-price (10% of the turnkey conversion bid) Pre-Conversion Analysis phase during which we employ our proprietary advanced application analytics software and work closely with you to identify those items that can be excluded from a conversion. The savings from performing this step can be quite substantial.

Q. What DON'T you convert?

We specifically EXCLUDE differences in performance arising from the following factors (Note: LCC may be able to provide excluded functionality for an additional fee):

• elapsed time required to complete an operation in the final application when compared to the time required to complete the corresponding operation in the source application on the same computer.
• addition or omission of typestyles, fonts, punctuation, color treatment or other non-functional or decorative elements on input forms, reports or other user interface elements so long as the interpretation of the item and overall impression and appearance remain substantially similar when observed by a reasonable individual.
• number, type and style of specific computer instructions, programs, functions, macros, icons, buttons or forms used to effect an action or process as long as the observable results of the process or action are reasonably similar in the final application to the observable results of the same process when undertaken in the source application.
• precise positioning, alignment and size of individual program elements so long as the interpretation, overall impression and appearance of the item remain substantially similar when observed by a reasonable individual.
• specific physical actions required to be performed by the application’s users to effect or initiate an action or a function such as specific keyboard keystrokes, menu selections and/or mouse-clicks so long as a reasonable substitute for those keystrokes and/or actions is provided in the final application.
• Form to form ‘zoom’ capability. Specifically the behavior a DataEase form exhibits when the user presses ‘F10’. (This functionality may be purchased for an additional $20 per instance).
• internal data storage formats, calculation order and locations so long as the interpretation of the data when presented within forms, reports or other observable areas in the application are substantially similar to the interpretation of the data when viewed in the source application by a reasonable person.
• any component process or functionality used in the Source Application that depends on or is activated by external command, batch file, external program, “terminate-and-stay-resident” (TSR) program, or Custom-Defined Function (CDF) library which is external to source application’s DataEase® run-time environment unless specifically accommodated in another section of this agreement.
• any component process or functionality that directly depends on data supplied by the presence of specialized input or output devices such as bar code readers, digitizers, cameras, scanners, digital scales or any other input device other than the basic keyboard and mouse.
• any programming or application design functionality provided by the DataEase® environment and accessed through the DataEase® “Main Menu”.
• any process or function that only exhibits deficient behavior in the final application using data or functions that were not present in the original source application provided by client to LCC.

Q. What do I need to have to run my new application?

Microsoft Access 2000 or better. This may be purchased as part of Microsoft Office or separately.

Q. What am I buying? Is this software or a service? Can I just buy the converter?

Q. Why is Access the target platform for the AMW?

Several reasons.

1) More of our customers ask for Access conversions than any other platform. Many IT departments are now mandating Microsoft platforms.

2) The technical challenges presented by Access are less formidable for most people comfortable with DataEase applications than in other environments. i.e. Access is simpler than most other options.

Q. What if my migration target is not Access? Oracle?

Microsoft Client/Server Platforms

For example, say you have a large database that outstrips Microsoft Jet's (the native database engine for Access) concurrency performance limits. It is a little-known fact that anyone can convert an Access Jet database to one of three acceptable database engine options for, essentially, NO CHARGE. The first option is MSDE (Microsft SQL Server Desktop Engine), which is a stripped down version of Microsoft SQL Server and is included in Microsoft Access 2000 and up. MSDE brings all of robust performance of SQL Server transparently to Access applications. What is not included are SQL Server's administrative tools.

Q. What versions of DataEase applications can you convert?

Q. What version of Access is the generated application compatible with?

Q. Ok, come on. The new Access application can't possibly convert everything from my DataEase application, can it?

Q. Why do you sell two flavors of your service (Unreviewed and Turnkey)?

Q. What if I choose the unreviewed option and then get stuck trying to make everything work right?

Q. Tell me about this 'guarantee' that accompanies your 'Turnkey' option.

EXCLUSIONS: We will not attempt to convert application forms or reports that make use of any third-party CDF libraries.

Q. You mention that procedures pose the biggest challenge to the process. They cost nearly 3x as much as forms to convert. Why?

A. DataEase DQL reports are procedural. That is, DataEase permits you to embed processing instructions within the record iteration loop(s) such as data updates and other 'sequential' complex data-handling algorithms. Access reports are strictly 'SELECT' query-based and support for embedding complex functions such as row-by-row simultaneous data updating and conditional output is poor. This poses a significant challenge when trying to build an automated conversion engine to handle every situation.

That said, reports that simply query a table and report the results generally need no 'tweaking' after the conversion. Even those procedures and reports that do are usually handled in a straightforward manner requiring no more than a few minutes of analysis and adjustment. Of course, there are always those 'monsters' that sometimes require consumption of mass quantities of brain cells. But we haven't found an 'impossible' one yet and feel comfortable we can execute the conversions within our published cost framework.

Q. I have a lot of applications to convert. Is there a volume discount available?