Developer Questions

[xpertsue]

I have been a long-time user of Lotus Approach, which is dBase (.dbf) based or interacts with other systems using ODBC (DB2, Oracle, etc). I have developed many applications with this platform, and I see Alpha as similar enough to consider. I have played with Version 7 and 8 and went thru your book in .PDF form. I still have some concerns:

1) I like applications to be "modular". In Approach the programming can be in multiple .APR files that all use the same set of .dbf files. Can I do this in Alpha?

2) I often collaborate with a fellow in the UK (I am in the US) on applications. In Approach we can work on different modules and only need to coordinate our efforts if we need to add a field to a table. How would I do this with an Alpha-based system?

3) I also develop and sell standard applications (order entry, survey, booking of hotel rooms, etc) in Approach currently. All a customer needs to run my application is a copy of Approach per user which I can get for about $15 a copy. How would I distribute my standard applications -- with a runtime for one fee in V8, I think. I am less sure of this in V9 due to reading other threads about pricing.

4) Is there a special version of Alpha 5 for developers to use vs "regular users"? If so, what is its cost?

I am considering V9 currently due to the new features, but I need to know the answers to the above before continuing with my "education".

Sue Sloan
XpertSS.com (support for Lotus SmartSuite users)

[DaveM]

Re: Developer Questions

1) I like applications to be "modular". In Approach the programming can be in multiple .APR files that all use the same set of .dbf files. Can I do this in Alpha?

YES

2) I often collaborate with a fellow in the UK (I am in the US) on applications. In Approach we can work on different modules and only need to coordinate our efforts if we need to add a field to a table. How would I do this with an Alpha-based system?

Using the copy to. You can work in your adb file and whatever you create can be copied to the adb, table with a copy to operation from the control panel. Suggest you keep one adb main copy and do your work in another similar. I also have done some collaboration.

3) I also develop and sell standard applications (order entry, survey, booking of hotel rooms, etc) in Approach currently. All a customer needs to run my application is a copy of Approach per user which I can get for about $15 a copy. How would I distribute my standard applications -- with a runtime for one fee in V8, I think. I am less sure of this in V9 due to reading other threads about pricing.

In Alpha you would purchase a developers copy for your self. Purchase a runtime for your users. You will have to look at the pricing from apha and maybe make a phone call to sales. If you are not going to use the sql side of alpha, you may want to purchase the smallest runtime available(not the rt engine) and it will cost you nothing more on distribution. If you are servicing a company that may have 20 consecutive users, you may want to go ahead and get the 20 user runtime. You can use this same runtime over and over and it is usable for a single user as well.

In short, V9 has the same option as v8, but have added a runtime engine that is at a perseat cost. The rt engine comes with the ability of sql. It also can be used in a network setting, so your data is on a server and all program files are on the workstation.


.

[xpertsue]

Re: Developer Questions

So, I can have multiple .adb files all using the same .dbf's. That is good.

Now, when I am co-developing, should we both have the same dbf's and sets defined? What if we both name a form the same.. will the "copy to" be ok with that? Due to the difference in timing we sometimes cannot communicate immediately as we work.

Sue Sloan

[DaveM]

Re: Developer Questions

Now, when I am co-developing, should we both have the same dbf's and sets defined?

YES

What if we both name a form the same.. will the "copy to" be ok with that?

no - you can't do that. If you are collaborating on an app, you really should have certain aspects of the app for each and the other should not touch. If there is a problem, you could have the copyto add the form to another table(that is ok), delete the original and copyto will workto replace it. I know it may seem confusing.

Due to the difference in timing we sometimes cannot communicate immediately as we work.

If you have mapped out your, you should have very few problems.

Your forms, operations, reports, labels and letters are attached to tables or sets. you can replace all the stuff for a table or set by copying the support files for that set. I would say, one of you should concentrate on certain tables and sets while the other works on the other tables and sets. Just how we did it.

Scripts and functions can be done and use the copy to. They belong to the adb.

[CALocklin]

Re: Developer Questions

Sue, a long time ago I used Approach because the company I worked for insisted on it. I left Approach when I left that company and would never consider going back.

To help clarify Dave's comment, the "developer's copy" is what Alpha calls the Full version. Don't bother looking for anything called a "developer" version.

As for collaborating, it sounds like Dave has done more collaboration than I have but I'll add a couple other possibilities:

- You can export global scripts and functions (those found in the Code tab of the A5 control panel) to a text file. These can then be imported into the other person's copy. When running the import (or export) you have to select which scripts/functions are to be imported. You do need to use some care in doing this because the import will overwrite any existing script/function by the same name. There is, of course, a Select All option.

- It actually is possible to use the same layout name in different tables/sets. I really don't recommend it because it seriously complicates the ability to call the one you want. However, I bring it up just to let you know that if it happens you will be able to 'combine' the two development versions then change the name when you discover the duplication. Remember, this assumes the layouts with the same name are in different tables or sets. (edit: I see Dave did sorta say that already but from a slightly different angle.)

- You can also create a form named XYZ and a report (or other layout) named XYZ and it will work fine even if they are in the same table/set. However, I consider that to be bad programming practice and highly discourage it.

- You can copy the complete "data dictionary" (each "data dictionary" consists of 3 files) for a table/set from one developer to another. This will completely replace all field rules, layouts, and operations that are related to that particular table/set. This is the best way to update developer "B" if developer "A" was the only one that made changes to that table/set. (This is what Dave meant when he said, "you can replace all the stuff for a table or set by copying the support files for that [table or] set" but I wanted to reiterate it because of the next comment.)

- There is a free utility (in the Code Archive on this message board?) created by Jim Chapman that allows you to export specific layouts (and scripts??) to a special file that can then be imported into another copy of the application. It's designed so that it can only be imported to the same application and table/set that it originally came from. This makes it possible to update single layouts without sending the whole data dictionary or without doing a "copy to" which can be more difficult when you are at different physical locations. (Although it could probably be done with a VPN connection.)

In short, I think you will find all the tools you need. If you can't find something, just ask and there's a good chance somebody knows how to do it.

[jjfcpa]

Re: Developer Questions

Sue, a long time ago I used Approach because the company I worked for insisted on it. I left Approach when I left that company and would never consider going back.

To help clarify Dave's comment, the "developer's copy" is what Alpha calls the Full version. Don't bother looking for anything called a "developer" version.

As for collaborating, it sounds like Dave has done more collaboration than I have but I'll add a couple other possibilities:

- You can export global scripts and functions (those found in the Code tab of the A5 control panel) to a text file. These can then be imported into the other person's copy. When running the import (or export) you have to select which scripts/functions are to be imported. You do need to use some care in doing this because the import will overwrite any existing script/function by the same name. There is, of course, a Select All option.

- It actually is possible to use the same layout name in different tables/sets. I really don't recommend it because it seriously complicates the ability to call the one you want. However, I bring it up just to let you know that if it happens you will be able to 'combine' the two development versions then change the name when you discover the duplication. Remember, this assumes the layouts with the same name are in different tables or sets. (edit: I see Dave did sorta say that already but from a slightly different angle.)

- You can also create a form named XYZ and a report (or other layout) named XYZ and it will work fine even if they are in the same table/set. However, I consider that to be bad programming practice and highly discourage it.

- You can copy the complete "data dictionary" (each "data dictionary" consists of 3 files) for a table/set from one developer to another. This will completely replace all field rules, layouts, and operations that are related to that particular table/set. This is the best way to update developer "B" if developer "A" was the only one that made changes to that table/set. (This is what Dave meant when he said, "you can replace all the stuff for a table or set by copying the support files for that [table or] set" but I wanted to reiterate it because of the next comment.)

- There is a free utility (in the Code Archive on this message board?) created by Jim Chapman that allows you to export specific layouts (and scripts??) to a special file that can then be imported into another copy of the application. It's designed so that it can only be imported to the same application and table/set that it originally came from. This makes it possible to update single layouts without sending the whole data dictionary or without doing a "copy to" which can be more difficult when you are at different physical locations. (Although it could probably be done with a VPN connection.)

In short, I think you will find all the tools you need. If you can't find something, just ask and there's a good chance somebody knows how to do it.

Cal

It sounds like your almost saying that you can only collaborate on an application if you are working in different data files/sets. This sounds extremely limiting in our case, (perhaps others too), because our application has numerous forms, more than a hundred forms, and only uses a couple of data files. Very often, we have two or three people working in the application at one time. Naturally, this application is not currently in A5, but we are considering moving it to A5, in which case, we might need 3 or 4 people working on it at one time.

Can you provide guidance?

[csda1]

Re: Developer Questions

Hi John,

Cal

It sounds like your almost saying that you can only collaborate on an application if you are working in different data files/sets. This sounds extremely limiting in our case, (perhaps others too), because our application has numerous forms, more than a hundred forms, and only uses a couple of data files. Very often, we have two or three people working in the application at one time. Naturally, this application is not currently in A5, but we are considering moving it to A5, in which case, we might need 3 or 4 people working on it at one time.

Can you provide guidance?

If you are currently have open the same database application on a shared network or Terminal Servers, only one user at a time can modify a specific layout (and others can be using the layout). Multiple people can modify the same items on the code tab, however the last write will override previous writes of those items, so be careful for those. For Indexes, Table/Set structures and Field Rules a user must be the exclusive user of that table/set. This normally is not something that multiple users would do at the same time, so it is not normally an issue.

If working on an unconnected copy of the database, then you will have the issues of making sure only the changed items in the data dictionaries, indexes and structures are updated from one to another.

[CALocklin]

Re: Developer Questions

To add to Ira's last comment, if you are working on unconnected copies of the database (a) it will obviously take a bit more coordination to make sure one developer isn't stepping on another developer's work and (b) it is possible for developer A to work on a form in Table X while developer B works on a different form in Table X and still be able to get those individually modified forms into one "master" table/set.

There are at least two ways to handle item (b):

1. The two databases could be put on the same system in different folders and the layout could be copied from one folder to the other. This is done by going to the A5 Control Panel, right clicking the form (layout) name and selecting the "Copy to..." option.

2. I think my preferred method would be to find the "Object Import/Export" routines that were originally created by Jim Chapman and use those. These routines export the layout to a ".abn" file that can be e-mailed and imported into a remote computer. (Don't ask me what "abn" stands for. I have no clue. It just "is".) I think those routines are posted in the Code Archive somewhere. A search on "Object Import" will probably find them.

[Keith Hubert]

Re: Developer Questions

Here are the two scripts Cal mentioned for creating and importing the ABN files. Right click in the white area of the code tab and select Import. The dilalog will show the two scripts to import.

These scripts have been a life saver for me, and I build them into all my applications.

I can send my clients a new form, report or routine and they press a button and their app is instantly updated.

One of the best parts of the import script, is that it deletes the ABN file after the import.

This would also be good for developers working on different parts of the same application, and slotting in each part to the master copy.

[mheller]

Re: Developer Questions

There's an obvious strategy if you're collaborating remotely and you might have a name collision on a new form: develop the form using your initials as part of the name. It's not like the users will ever see the name.