Field rules - lookup - lock up

[Sue Reuser]

I have a sheep set with a child db breed00 with number as the link. I'm trying to set up field rules for breed00 with a lookup in the sheep db to fill the number and name fields. I have actually gotten it to work and have entered about 30 records but the lookup table gets weird with a whole bunch of the same record number listed and then eventually locks up. I've tried changing the field rules every way I could think of but nothing helps. I have gotten this to work in the past years but I can't figure what is going on now. After it chashes and I reboot and go back in to Alpha 5 I can enter at least one record and it works perfectly. It makes for awfully slow data entry though.

Sue

[CALocklin]

RE: Field rules - lookup - lock up

Sue,

I can't give a direct answer what you are doing sounds strange to me. If I understand correctly, the child database is trying to look something up in the parent database. This is probably wreaking havoc with indexes (esp. in version 1).

If the data is already in the parent table, why do you need to add it to the child?

Could you post a few more details or some of the application so I could understand better what you are trying to accomplish? There may be a better way.

[Sue Reuser]

RE: Field rules - lookup - lock up

I have my main db "sheep" that contains all the info on each animal. I make a breeding db each year that includes the mating info for each ewe and calculates the expected birth dates. As I am entering this information I would like to get the id and name of the ewe from a lookup so I don't have to type it. I also want the id and name fields to be the same as in the main sheep db with no misspellings or forgotten numbers or letters.

It's obvious that I didn't do it right but I did manage to get the data in for this year with a lot of patience and many crashes. I figured out that one thing that I had to do was move the lookup window with my mouse higher on the screen every time it popped up (every record entered) and that let me scrol through the data ok.

I will also be wanting to record the lambing info for this year in another db. It will be a similar situation as I will have to add new data for each ewe. Some of fields I will want to be included in the sheep set but not all. How can I set this up? Should I try to expand the breeding db? The ewe id and name fields are already there so maybe the data entry would be faster by just using the change record and a brouse.

Thanks for your help. If you want me to attach files please explain which ones.

Sue

[CALocklin]

RE: Field rules - lookup - lock up

As I am entering this information I would like to get the id and name of the ewe from a lookup so I don't have to type it. I also want the id and name fields to be the same as in the main sheep db with no misspellings or forgotten numbers or letters.

The question is why? Since the data is already in the parent table, why do you need it in the child table? Is the child table used in another set somewhere without the parent? Or, is it for a report based only on the child table only? (If the latter, why not base the report on the set or an inverted set where the child becomes the parent?)

Don't get me wrong; I'm just trying to understand what you are doing. One of the basic reasons for a relational database is to avoid duplicate data entry. However, sometimes it's necessary. My first question then is, "Is it really necessary in this case?"

If you want me to look at your app, you can e-mail it too me at [email protected]. If so, the best bet is to zip and send the whole thing - all the dbf, mdx, fpt, ddd, ddm, ddx, apd, apm, and apx files.

[Sue Reuser]

RE: Field rules - lookup - lock up

I do appreciate your help. I think that my main problem is not being a programer and really understanding how to create the data base. Maybe it is also the terms that I am using. No, I don't want to duplicate data and I hate data entry and I'm lazy. That is why I'm using A5. I have my main db that has the info that I want on the animals that are currently in my flock "sheep". I have others for events breeding, lambing etc. Am I supposed to do my data entry in the set by changing records rather than the child db? That doesn't make sense. This info will just be used for a short time. Some "lamb" info needs to get put into the record for the ewe. Some lambs are added to the flock and some are sold before putting them in the sheep db. Years ago I took the time and set up an invitory db for our business that was run by menus. Others used it and it worked OK but was never changed. I'm afraid on this one that I'm using myself that I haven't taken that time and I've been using as I go and add to it as I need more info. I pay for this technique because I don't use it enough to remember everything. There is a lot more that I could use Alpha 5 for but I have been afraid to because of all the trouble that I've had with it. I've also spent a bunch a money on tech support only to have the problem blamed on indexes and or hardware. I have lost data permanently. I suppose that might have been hardware because I've replaced equipment but I haven't lost data in other programs. You daid something about v.1 Would updating help? when I ask before I was told upgrading wouldn't help for what I was using it for. Where do I get a zip program?

Sue

[Melvin Davidson]

RE: Field rules - lookup - lock up

Sue,

I believe there are two solutions you have not considered.

The first, and easiest is to create a "reverse" .set.
That is your set is currently similar to

[Melvin Davidson]

RE: Field rules - lookup - lock up

Oops, sorry..

Sue,

I believe there are two solutions you have not considered.

The first, and easiest is to create a "reverse" .set.
That is your set is currently similar to

sheep
|
- breed00

But you can easily make a report that gives you the information you need by creating a second set as

breed00
|
- sheep

A second solution is to simply create an UPDATE
for the breed00.dbf that uses the lookup to enter the data
for you.

I must, however, agree with Cal. If you have the data in the Master db, there should be no need to enter it in the child. A report can easily be created that just prints details of the child db and also uses info from the master.

Regards,
Melvin

[Sue Reuser]

RE: Field rules - lookup - lock up

Melvin,

I think that some of your comments were left off the reply. What is a reverse set. That is not in my book.

Thanks
Sue

[Sue Reuser]

RE: Field rules - lookup - lock up

OK I hope you don't mind me doing my thinking out loud. I start with my blank breed00 and make it a set linking to child sheep by id no. Can I set up a field rule lookup for the id no (the link)so that when I am starting the data entry I'll get a popup list with both the name field and id number fields? I know some of the sheep by name and some by number. Also the nos are a little complex since it is a link it has to be entered exactly. That is why I want to choose from a list. When I am looking at my data whether in a browse or in a report I always want the 2 fields id no and name included regardless of the other data.

I guess I have been linking the wrong direction. I'll go back to the book again.

Another solution that might keep me out of trouble as I add more stuff. Go back and add another field. Is the record no field kept the same forever or will it change as packs etc. are done? I could give each sheep a computer number for linking and data entry purposes and keep a printed list by my computer.

I really appreciate your help.

Sue

[CALocklin]

RE: Field rules - lookup - lock up

Pardon me if I'm explaining something you already know but I've run into this misunderstanding before and it sounds like you might be having the same problem.

I'm not sure what your tables are named (pardon me, in current lingo, 'table' refers to one .dbf file and 'database' refers to all the .dbf files in an application) so I will assume the parent table is 'Sheep' and the child table is 'Breed'.

The parent table should have one field that is unique for every record. This can be a number that you assign to the particular sheep or it can be an auto-incremented field. Do NOT use the record number because, as you suspected, the record number will change when you delete and pack other records. The child table, Sheep, should have a matching field defined (type and length) BUT it should be defined as "user entered" rather than auto-increment. This common field can now be used to set up the link in a set between Breed and Sheep. (see set naming HINT below) If the unique field is autoincremented then you don't even need to display it on forms because you don't need to fill it in. NOW, if you use a form based on the set to create the Sheep info, then the unique value from the parent table will automatically be added to the child table when you begin to enter the child data. In fact, the default form for a one-to-many set will not show the related field in the browse area for the child table because it isn't needed.

What this means is that you can search for the correct parent record based on either the name or the number and then just start entering the data in the child table.

OK, now that I've said all that, there is still the possibility that you already have the child data and need to connect it to existing parent data. This is harder but I think it can still be somewhat automated. Let me know if this is the problem and then I'll see if I can come up with a solution.

NAMING HINT: Use a unique name or, my preference, put "_set" at the end of all set names, ex: "BrSh_set.set", otherwise reports/forms/etc. will be shown as being contained in, for example, "Breed" but you won't know if it is in "Breed.dbf" or "Breed.set" until you open the layout in edit mode. This really becomes an issue when you convert to any version after v1.

BTW!! are you using version 1.00 or have you updated to at least v1.02 - if not, do it now! (It's free.) My suggestion would be to seriously consider upgrading to version 4.5 or the soon-to-be-released (we hope) version 5.0. They are a bit different than version 1 but the learning curve is quite easy compared to the change from A4 (DOS) to A5. This probably won't solve your immediate problem but I think you will find the later versions easier to use as well as being more powerful. And, since I doubt you are using any serious Xbasic, all your current programs will probably convert with no trouble.

OK, one last hint about this board before I hit the hay. You only need to check the "If someone posts a reply..." box on one posting for any given string; you will continue to be notified of any subsequent postings to that string. Checking the box again doesn't hurt anything - it's just not necessary.
G'nite!