Sounds like you need to consider using a Database for this. You would have a table for students, their ID will be the primary key. You will need another table that lists the available subjects, with some unique ID for each one of those. You will need a cross-reference table to join Students with there subjects. It will consist of two fields, one for the Student ID and one for the Subject ID.

From there you will need two similar tables for the entries that links them to the proper subject.

Not using a database on a complex problem like this tends to make your code 700+ lines; using a database on a problem like this tends to make your code MUCH smaller:

select students.lname, students.fname, subjects.name, entries.name
from students
left join subjects on students.id = subjects.student_id
left join entries  on subjects.id = entries.subject_id
where students.id = ?
order by students.Sex, students.lname, students.fname
[download]

Databases by themselves are beyond the scope of this site, but be sure and read up on DBI.

jeffa

It should work then my hash is ok? but i still cant find why a hash with different key also gets the value of the original key i wanted to access. Ex.



$TT{1000001}[1][1]  = '4342';
$TT{1000002}[1][1] = also gets the value!
[download]



Im about to finish this so i cant just start from scrap again & co'z i dont know how to use DBI yet, i have been coding on Perl for only 2 months.

Please stir me to what part of my code is the problem! and also please advice on how to best make do to what im currently using!

And a note was posted on ChatterBox that in perl "there is No such thing as associative array but their is hash that is Similar to it in Perl", i thought that, hash and associative arrays where both the same! if so "Perl for Dummies" is really Dumb? it named that function as associative array! thanks!

Ahh . . . because they point to the SAME address space. This happens when you are not careful when assigning references. Again, pull out Data::Dumper and see what is really happening.

Oh, and associative arrays ARE hashes. A hash is simply an array whose indexes are assicated with a key, a key is simply a value that is 'hashed' to produce the proper index slot. When two keys share the same slot, they are said to 'collide' with each other, and a list is created to hold both values for the key. Keys that are very similar tend to collide, such as 1000001 vs 1000002.

jeffa

I believe what you saw on the chatterbox was perhaps a bit of word play.

An associative array is as The Dictionary of Data Structures says, an abstract concept that extends the idea of a data structure indexable by numbers to an array indexable by keys, or by the association of a key with a value.

It may be implemented in a number of ways including the way that Perl chose, a hash table or hash for short. Ideas like this are present 'natively' in many modern languages and in libraries in older ones. They are called many names, often deriving from their implementation, including collections, dictionaries and hashes.

An Associative Array is then the general term to apply to all of the above. For instance it is notable that the term is not present in any of the indexes of Knuths Art of Computer Programming, specifically vol 3. Hashing however is covered in detail and is considered to be a subset of the over all problem of searching, along with Binary Trees, Linked lists, B+Trees, etc.

HTH

Yves / DeMerphq
--
Have you registered your Name Space?

I already told you why you are having the problem. Delete your initializations of $TT{1000001}[1] and you will eliminate this bug when you try to access $TT{1000001}[1]. If you want to remember that what you are dealing with is named 'mname' (and yes, I consider it good to keep this kind of textual context around) then you can use a hash of hashes of arrays rather than a hash of arrays of arrays. Accessing that would be written as $TT{1000001}{mname}[1], and again it is important not to initialize $TT{1000001}{mname} or else you can get into the same error.

Furthermore if you want to avoid the possibility of this bug or any of a number of other common bugs happening, you can use strict, and declare each of %INPUT, %STUDQT, @sorted, and every other variable with my. If going through and putting in the declarations is too much work for you, you can just catch this bug with adding the line:

no strict 'refs';
[download]

at the top of your program. Note that for any program over 20 lines, my experience is that the time saved in tracking down typos amply pays for the effort of declaring everything with my. My experience seems to be par for the course among experienced Perl programmers.

So if you want a quick fix, remove the dangerous initializations, check for strict references using the line I showed you above, and continue on.

But a piece of advice from much painful experience. One of the biggest things every programmer needs to learn is how easily you can think that you are just about to finish when you are not going to finish any time soon. The mantra, "There is just going to be one more bug, this one is it!" can go on for months. Or for larger projects, for years. It is, in fact, quite common for a year long project to appear to be on schedule until 2 weeks before the deadline. Then it starts to slip, and the estimate stays at about 2 more weeks. It can then easily continue to slip couple of years of developing and bug fixing, always seeming to be about 2 weeks off before it is finally cancelled, unfinished.

Based on the code sample that you have shown, the length of what you claim the code to be, and your inexperience, I strongly suspect that you are about to get a milder form of this lesson first hand. Please don't take my saying that personally. I am saying this based on memories of my own learning curve, how difficult I think that code organized that way would be for me to work with, and knowledge of how virtually all programmers tend to chronically underestimate how much work is really left.

That said, unless you can find a mentor who can really work with you on the design of your code, I don't think you are likely to do much better by trying to rewrite from scratch right now. But make a point of redoing this project from scratch when you have some more experience. If you have only been programming Perl for 2 months, and don't have a lot of programming experience, then you should be on a pretty steep part of your learning curve. When you have learned a little more, you should find that you would do things rather differently, and doing them differently will really make a difference. It is worthwhile sometimes to remind yourself of how much you have learned.

And to help that learning curve along, I would suggest the following:

1. As soon as you can, read tye's article, strict.pm. It will tell you a lot about how Perl can make your life easier for you.
2. Read Coping With Scoping, by Dominus, because that will help you to use strict.pm effectively.
3. Read use CGI or die; for the quick demonstration of how to use the param() and header() functions from the classic CGI module. When you know how to use those, you should not want to hand-roll that code again.
4. For more on what symbolic references (the thing that is biting you) are, and why they are so dangerous, read avoid symbolic references by Dominus. Read all three parts, largely because it has a wonderful explanation of why modularization of code matters so much.
5. To gain a better understanding of references, read references quick reference carefully. Also figure out how to use Data::Dumper, and start using it to create debugging dumps of your data structures. That will allow you to see how what you have in there compares with what you think is in there.
6. As soon as you can, pick up some good books about general programming. The usual one I like to recommend is Code Complete.
Good luck.