2 noob questions

[DirectX]

Hello all,

First of all i am very happy that I found this software!

Now questions that are very important for me at this stage:

1 - Can I first create Customer and such lists and when its all done than start to connect them between each others?
2 - When software is done can it be exported in .exe file for customer PC's or it can be just used from AlphaFive software? I do not understand on the end what I need to compress everything and create installation file of my application.
3 - Advice me with steps that are for total beginers to make me faster understand this software.

I know I will need a year or two to come at this stage where I need this but for me is very important to understand process steps before I start...

Thanks

[CALocklin]

You don't say how much database experience you have so, before you start building tables, let me suggest that you should read at least one book on database design and get either Dr. Peter Wayne's book on Application Programming in Alpha Five or Susan Bush's book titled Alpha Five Made Easy. Dr. Wayne's book was written for A5v5 but everything in it is still applicable to A5v7.

You might even want to do some reading up on database normalization but, if you look at that link, please start by reading the sections on Redundancy and Unforseen Scalability Issues because those are the primary reasons for normalization. Don't get all wrapped up in the details for now - just try to understand the basic concept. (You can also find plenty of other links on the web by searching on "database normalization".) Many people may not like the fact that I even bring this topic up at this stage but I'm doing it because of the frustration I've had to go through when getting applications from beginners that were so badly designed that they couldn't get the results they needed, brought it to me, and I had to start over from the ground up. Again, it's the concept that is important. Leave all the gory details until later. Especially don't even bother reading about 4th or 5th level normalization for now if you happen to see anything about them.

Now, to answer your immediate questions:

1. Yes. You can create each table separately then combine them into sets later on. In fact, that's what you must do - it's very difficult to add tables to a set if the tables don't exist. If necessary, you can always add more fields to the tables even after the sets are created. You can even delete fields that aren't used. Of course, creating the sets (at least the basic ones) is normally done right after the tables because you will need them to add forms, reports, and other layouts that use the related data. Moreover, the first step should be the design concept on paper which will show you what tables and sets you will need.

2. You can distribute your application to users (even multiple users) by combining your application files and a copy of the runtime edition of A5 into one install package. Although the result will be many files on the user's system, there are many of us who would scream and yell very loudly if Alpha decided to force us to use a single executable file a la Access. We much prefer the "multiple file" method because it is much, much, much easier to maintain after it has been distributed. (I speak from experience, I have maintained applications using both methods.) And, please do not try to tell me that "everyone else uses single executable files" because even my old version of MS Office 97 has over 400 files and that is just a basic installation - and my copy of MS Flight Sim has over 41,000 files and required 4 CDs to install. For now, just trust me - you do not want a single executable file. If you are concerned about protecting your code, there are other ways to do that.

Finally, one last (long) comment from me. Think about building a good database as a little bit like building your own real airplane from a kit rather than putting together a toy airplane or even a radio controlled airplane. Lots of people do it very successfully but it does require a lot of time, effort, care, and study. Those who don't put in the effort are going to find themselves in trouble. (If your radio controlled airplane crashes, you may be out a couple thousand dollars but it won't cost you your life or affect your business.) The amount of effort will depend on the scope of the project - if all you want is a contact database (or an ultralight glider), minimal effort is required; if you want to run a multi-million dollar business (or build a jet) a huge amount of effort will be required and you should probably find a professional for all but the grunt work. Of course, most do-it-yourself databases fall somewhere in between those extremes and I encourage you to go for it. But beginners shouldn't make the mistake of thinking it's as easy as building a spreadsheet - I'd say it's at least 10 times harder and, in some cases, 100 times harder. Building a good database application takes a lot of thought and effort so study up on it before you start and things will go much faster and smoother later on. Good in this context means: easy to use even for temporary employees, easy to fix when necessary, easy to add new features to without changing old features (a fairly common problem with poorly designed applications), and protects data integrity by (a) helping users to quickly enter the correct data and (b) not allowing users to enter the wrong data or leave out necessary data.

(This was started 2.5 hours ago and, after many interruptions, I wonder what's been posted since I started?)

[Tim Kiebert]

The reply from Cal is from the experienced expert category. I thought I might give my 2 cents as a new user.

Even though I have had A5 now for 18 months I didn't actually build anything usable for the first 8 months. I was using another program so was not in a hurry. Even though I had put together a couple of mildly complex databases with the other program I had never really learned the basics having been thrown in the deep end at the time. I basically did what Cal has suggested as far as learning goes. I just searched the net for info on database design etc. You'll find heaps out there.

I made extensive use of the Alpha sports sample database. Make a backup copy of it and then just start experimenting with it till you make a big mess of it. Then delete your mess and start with a fresh copy and try some more stuff.

Make sure you download the large version of the help file and update it as often as you can. It is updated regularly to include new stuff and correct the odd (dare I say) slight error. That same help file is also available online and is always the most up to date. There are also PDF versions of of the help in smaller chunks depending on what you need. While using the help file I try and read a couple of related items after I have found what I am looking for. This gives a bit of a wider view on the problem at hand and sometimes you find some real little gems (like a special function ) that you can tuck away for later. There are also tutorials and examples in there that you should not go past. Speaking of examples don't forget to look in the sample folders under the main program directory.

Explore all the links around the Alpha websites. Their are tutorials to watch, newsletters with articles to read and an archive of past news letters. This Forum is also great. I often download the examples given to help solve someone else's problem as they are a great way to learn different techniques and gives you an idea on what is possible and sometimes what to avoid. And don't forget to use the search feature.

There is that much info out there that you could soon suffer from information overload. A couple of the main points that helped me out of all that info have already been mentioned by Cal.
1/ Design your database on paper before putting finger to keyboard. Part of that designing is getting a good understanding of the actual data that you are dealing with and then working out what you actualy want to do with it. This sounds obvious but I have often just jumped in and later realised that i was taking the wrong aproach.
2/ The subject of Normalisation sounds daunting if you haven't come across it before. I think it might depend on whether you are a left brain person or a right brain person. Don't think that just because it was suggested by an experienced person that it is beyond what you need. Like Cal suggested, I learned the basics and it helped me understand how to organise and seperate the data so that it could be worked with. This will make it easier when it comes time to put sets together.
3/ Getting a grip on set structure was important for me. ie one to one, one to many, and manyto many relationships.


Hope this helps in some way

[DirectX]

hi

Thank you guys!


First of all I will try to understand all steps required to make a software, for example table creation, filed rules, forms, reports.... and when I completly understand steps that are required to make software than I will go in details of each of them
This because it is just a way that I learn all stuff... if I do not understand process than i get confused very often. Im not sure if this is good or not but its just the way it is ;)