crtreedude

I would think you want to look at UNION under MySQL.

Unless I am confused this morning, an Insert never has a where because what you are inserting doesn't exist in the table yet, so why would you care about the where clause?

Got it, so if the job_offering is linked to a user/company pair, and the relationship between the user and company drops, what happens? It seems perhaps that you are assuming that the relationship between a user and company will last as long as the job offering - always. Is that so?

And interesting question perhaps, if a user can only belong to a single company, and a company can only have a single user, why not put user information inside the company table? Unless you have another table which user is connected to directly, but then again, it seems everything is related through company fair warning, I am a real geek on this stuff since I did database design for more than two decades.

Then there is no reason to link job offer to anything other than company, is there? Or can a company be in the list more than once, and the user permits uniqueness? If so, you need to have a separate table for company, and an intersect table between user and company which then can be connected to jobs.

What I see here is a user can have zero to one relationships with a company, so a company can only have one user? If this is true, why bother with user_id in job_offer since by selecting the company, you have selected the user_id Normally I would expect to see a one to many relationship from company to user, just as you have a one to many relationship between job offers and company. Just wondering

Perhaps a couple of questions. How many diseases are there, maximum? What are the reports you wish to produce? How you store the data depends on how you wish to use the data. For example, if you were merely going to show which diseases a person has, there is no need to be able to search on those diseases, so you can do whatever trick you want to compress the data. For example, you could, if you wished, create a binary representation of the options, and store the results of your check boxes as a binary number. Then, when display, decode that binary number and show the diseases. But, if you wish to do analysis on the diseases, then the master / child relationship is a very good one, because though there many be thousand potential diseases, a person normally won't have more than a small subset of those, or one would hope. So, the examples you are getting with two tables are very good. If you develop other attributes, you would wish to put them either in another table, or change your disease table to be something more generic, and a code to say whether it is a disease, an alergy, an injury, etc. hope that helps.

I will second that it is a charset issue. A few useful commands since I just spent 3 days resolving accents in Spanish. $charset = mysql_client_encoding($conn); printf ("current character set is %s\r\n", $charset); This will show you what encoding that your client is using. mysql_set_charset ( 'utf8',$conn); $charset = mysql_client_encoding($conn); printf ("current character set is %s\r\n", $charset); This will set to utf8, and show that it actually happened. Web browsers can show you what encoding you are using on page. Hope this helps. It is worth reading about encoding, character sets, etc.

Sorry, I didn't complete a lot of the statement select * from items a where not exists (select * from Items b where a.itemid = b.itemid and b.primary = 1) I haven't tested it, but something like that should do it.

If I understand correctly, you should use a subquery select * from items where not exists (select * from item where primary = 1) In this way, if the itemid has ANY record where primary is set to one, it will not return that itemid Is this what you are looking for?

It would seem to me that you need a detail table, which uses both your patient and billing table (since it appears your billing table is billable codes or something) You need a table for the invoice, and then you would have the detail for the invoice. Or so I would think.

What if it would take longer to fix the current code? That would be first response, now would it? Another one, a good programmer knows how to use debugging and trace tools, and actually uses them - and if SQL, knows how to profile queries. In other words, a good programmer knows how to use the right tool for the right job, which includes finding bugs and performance issues. He / She doesn't just sit there staring at the screen hoping for divine guidance or something.

Try typing in directly into a field and then reading it back, I bet you find that the Management Studio is not setup to show your UNICODE. I know the Query Analyzer never did - to see the characters, I had to use a program I wrote.

Just a comment - this is the answer. Not to the error, but why you had the problem. Beginning programmers actually think computers do what we tell them, old geezers know better. I have 30 or so years experience writing code and I can tell you it ain't done till you check all the lines. Learn to use debuggers and traces - or pull your hair out. And learn to do unit testing. Okay, ole geezer lecture over, for now.

I good programmer's first response in seeing someone else's code is not to say it needs to be rewritten...