Developer Vs Runtime

[Bill Pope]

I have one copy of A5 Ver-10 Developer. My situation at work is that I have three users including myself who will each need access to the database. What are my options? Do I need to buy two additional licenses? Do I need runtime? The information available on the Alpha web site is a bit confusing. Thanks.

[Clunes]

Re: Developer Vs Runtime

If you buy the runtime all you need to do is load that on the users machine and then point a shortcut to the adb. It will run. If you want users to do development level work like create their own forms etc then yuo need to put the developer on their machine

Runtime comes with unlimited license so you deliver your db to anyone you like.


I do my development on my machine and have 15 other users who have the runtime. all works great

[MikeC]

Re: Developer Vs Runtime

Bill,
Depends.....

That is as specific as I can get when

need access to the database

is what I have to go on. "access" means what? Access to the data==runtimes. Access to modifying the application==development.

Are you going to continue developing the application? If so are the users going to be using it when are actively developing? (suggest then 3 runtimes in addition to your current development)

Do the 3 users use the application all at the same time? If not, and if there would only be one user ever using the app, then a remote/networked connection could be used with just one runtime.

Soooo......any of my guesses right!? :) Bet with more info, someone will be able to give you a more exact answer! (I obviously can't!).

[Bill Pope]

Re: Developer Vs Runtime

Thanks for all the replies. My two other users will likely be accessing a few of the tables all at the same time, and I WILL be tinkering with the application probably until the end of time. I have been using Filemaker ever since Lotus dumped Approach and am always finding new things I want to do. I'm not sure how the runtime works. If I can modify the application on my desktop and then apply the new fixes to the other two machines during down time, that would be a perfect solution if it is possible. The users will be doing no development.

My understanding of runtime is that you can have as many users as you want sharing the same application over a network. Mike C mentioned something about "three runtimes", which has me confused even more. Is it possible to purchase only the runtime licenses you actually need? I run a very small department and my user base will not get any larger than two users plus myself.

[Clunes]

Re: Developer Vs Runtime

Bill

The current deal is for unlimited runtime. You as the developer can limit the runtime if you want. There use to be a process where you could only buy the license you needed, but the unrestricted is pretty good price so "I think" not necessary anymore. In your case the unrestriced runtime will not hurt. If you want to develop at the same time, then Alpha has a great zip tool. You develop and when you want to overwrite the main files you zip up less the data (a simple checkbox tick) and then unzip over the main files. However, as with approach, if you make table changes, then you will need to have a method of updating the data so that you do not get errors later

I loved Approach and used extensively. still have some very complex files out there that I will not change to Alpha unless absolutely necessary. I did not find a comparable product until Alpha5, that came close. I moved to Alpha and with some guidance from their great training vidoes got to a pretty good level very fast. The only thing I really miss from Approach was the added flexibility of the Lotus Dialog. Alpha's dialog is good too but just not quite as good. Trade off is the number of function Alpha have makes things a breeze. I have also found Alpha more stable for users. All in all I believe Alpha is developing a superior product and unless someone sells the company to IBM like Lotus did - which totally stoped its development - then all should continue to grow.

[Bill Pope]

Re: Developer Vs Runtime

Thanks Mark. It sounds like runtime is the route I should take.

[Ted Giles]

Re: Developer Vs Runtime

Go Runtime, but really do take note of the problem if you "tinker" with the tables as the data will be all over the place.
It will offend a few purists, but I tend to add a few single char fields to each table as I KNOW that the users will ask for another field.
Something else I have had problems with recently. If you add a field and save the table, apart from the warning it's usually oK. If you add a field and then move it up the list to be more logically placed, it sometimes wrecks the whole table. Suggest you replicate/copy the table and "tinker" with the original so if all goes bang, you can get it all back.

Ted

[MikeC]

Re: Developer Vs Runtime

If you add a field and then move it up the list to be more logically placed, it sometimes wrecks the whole table

I have read that when adding definitely add to the bottom of the table's field list to prevent issues....that said, what you did would most likely be fine if you had first saved it prior to moving it....otherwise you actually were not adding the field to the bottom. I do this a lot without issues...but do it one step at a time (just like most of the programming in Alpha!).

[Ted Giles]

Re: Developer Vs Runtime

LOL Mike
First time it happens you think you're going mad!

[Bill Pope]

Re: Developer Vs Runtime

Thanks for the heads-up Re tinkering with the tables. Fortunately, I have good backups and can always restore a table. I'll probably learn my lesson the first time it happens to me

[Raymond Lyons]

Re: Developer Vs Runtime

Go Runtime, but really do take note of the problem if you "tinker" with the tables as the data will be all over the place.
It will offend a few purists, but I tend to add a few single char fields to each table as I KNOW that the users will ask for another field.
Something else I have had problems with recently. If you add a field and save the table, apart from the warning it's usually oK. If you add a field and then move it up the list to be more logically placed, it sometimes wrecks the whole table. Suggest you replicate/copy the table and "tinker" with the original so if all goes bang, you can get it all back.

Ted

I have read that people experience these kinds of problems. However, for well over 10 years I have changed field names, have added or inserted fields both at the end and everywhere else in the table and have moved fields up and down the list without any problems (a name change, of course, does have consequences in coding). So I just wonder what is going on when people do have problems with such changes. What have I been doing differently, if anything? I have no idea, but I have seen no reason to become paranoid about making these kind of changes or even to follow the sometimes suggested rule to "Always add new fields to the end of the table" (I do that except when there is a good reason not to, which is quite often). Of course, one should ALWAYS have a backup before making any significant change to anything.

Raymond Lyons

[Keith Hubert]

Re: Developer Vs Runtime

The ideal is to have s separate development area where you can tinker as much as you want. When that is thoroughly tested bring the relevant files and/or layouts into the live area.

Read the attached article, you may find it of interest or even useful.

[Clunes]

Re: Developer Vs Runtime

Raymond, if you are not experiencing issues with your changes or mods to the tables then I presume you are actually always making those changes to the live db. My comments are based on doing development in a duplicate db while the user is working on the main one. Once development is ready for update then you need to be able update the users db. If there are table changes then you will need to make sure there are steps to meld the data and indexes.

Two things are apparent to me.

1. If you are making changes to the live DB while others are working with records and scripts you are in peril of serious corruption to the whole DB. Someone please correct me if I am wrong.
2. If you are doing point 1 and not experiencing issue then you are either very lucky or I am missing something, so again please correct me.

[Ted Giles]

Re: Developer Vs Runtime

Raymond, in the early days, re-oredring a table would sometimes - but not always - result in a screwed data set.
More recently using V9 I've had to hack a huge number of tables (Well 28 actually) about and all were absolutely fine.
Then I tried a simple change in V10.5 and bang. The changes to V9 were on and XP Laptop, the V10.5 are on a Win7 64 bit laptop.
I tend to back everything up before fiddling now as I sometimes get carried away in all the excitement!