Muddy_Funster

it's a sour pill, but sometimes when your working with a 3rd party system you need to make concessions for mistakes/inflexability in design. Just run it on a 64GB dedicated server and youll be fine

if those fields are directly relational integer fields then yeah you would.

That's a bit of a broad stroke in my opinion. It could have been done right as to what the specification was at creation. This is not by default what it will be three months or a year down the line. Really? because when I tried it one time it only threw forign key constraint violations which I assumed was due to the cascade only deleting the values used to provide part of the unique key index and not all, thus atempting to force what would be duplicate records. Love the ideal world thing you got going on there Unfortunately sometimes the only feasable scenario, especialy when trying to integrate with legacy systems which already do just that, is to build a key indipendantly into the table. I suppose I'm just bias - I spend most of my time in databases trying to plug into structures that have been badly designed, to facilitate visability and reporting on data for new systems. So I instinctivly distrust building keys in that way, preffering to opt for something I can controll directly. Looking at it from a lees subjective point of view, what you say is perfect sense in relation to a ground up build.

either your messing up the case in the function call or phpFicker.php does not contatin a function by the name of uploadphoto()

"ON lakestmill.company = units_1.company" This looks like you are joining on column that holds the company name as a string value. If this is the case is the spelling, white space and case exactly the same on both tables?

Don't use LIKE for exact values, use = Like will work through the contents of each record of each field bit by bit to build matches, = compares the record entry for the field as a whole. This should speed things up a bit. Also, why are you joining the same table so many times?

You could pull the entire $_POST into an array and work through indexed values rather than names. Although why you would want to let people, who have no idea how to actualy use a database, anywhere near one baffles me.

Yeah there is and I already said why. What to you is the difference between a primary key and a unique index? How much fun would it be if by accident/corrupition/design one or both of the joining tables was truncated? How about a member leaves and a new one gets assugned the original record ID, then want's to sit the test? A member leaves and you delete the record from the member table, which cascades - either you won't be able to, or worse still, your join table is completly unusable because of duplicate entrys. And all the rest. Primary keys, if used, should never depend on anything outside the table they are applied to.

without having the first clue what company, how we ment to help?

There are a couple of ways that are effectivly the same - you loop through the recordset that is returned and then add each value in turn into an array, either defining the array key with a counter, using array_push or letting it build a multidimensional array. All that really changes is the type of loop and how you choose to get the info into the array. I'm not versed in mysqli, but if you want an example in mysql or sqlsrv shout back.

You could have a look at this: http://dev.mysql.com/doc/refman/5.5/en/insert-on-duplicate.html, although I'm guessing this is an issue with the compound unique index that was brought up on the other thread, rather than on the the primary key, so I don't know that it will be a massive help on this occasion. Another thing that you could do is expand the index to include a timestamp, that would auto populate, if you are looking to hold historical information about the number of times a question has been answered by a perticular member, and what those answers were, which you could then archive off however you see fit.

IF (mysql_num_rows($result) = 0) wrong number of = , you need at least 2

you will need to put the session_start() code at the top of every page you have that will be visited within the session, otherwise the session will be droped.

The problem with this is that the third var never changes and therefore this does not determine all of the possible allocations. Thought this is probably a good start to the solution. Yes it does: $var_3 = 1 - ( $var_1 + $var_2 ); so as each of the values for the first 2 vars changes through each of the loops the value of the third will also change. Just out of curiosity, because I can never get my head around this - this will generate 1million combinations using just the 3 vars, right?

comment out the two lines that have "session_register(xxx)" on them, and add "session_start()" to the page directly under the opeing php tags. the problem with the header is that it can't perform the action because the warnings are being thrown by the depreciated function and as such there is information being passed to the screen before the header call - which just doesn't work.

eek, I've not used JQuery yet

can we see your javascript code please?

And again... { $pass = <your hash algorithm>($pass); $result =$this->db->query("SELECT <id field> FROM tbl_userauth WHERE <user name> = $uname and <password> = $pass"); change the parts of the code that have <> around them to your system specific values.

{ $pass = <your hash algorithm>($pass); $result =$this->db->query("SELECT <id field> FROM tbl_userauth WHERE <user name> = $uname and <password> = $pass"); change the parts of the code that have <> around them to your system specific values.

this is actualy an HTML question - here have a look at this: http://www.hyperlinkcode.com/bookmark.php

Your primary key should be a unique field identifier for that table, so id in this example. You can make a compound unique index of the member_id and question_id, using both as forign keys, as well as your PK, but PK's should be table independant and not require a relationship to other tables for their uniqueness. This allows for easier expansion and re-use of key values within the other tables without breaking the cross reference table.

Absoloutly not a problem, I'm not really the "do someone elses JOB for them" kinda guy anyway, which is what I assume you take to be a "real" professional in your broken little mind.

Not a fair assumption to make, you could be copying and pasting segments of code from within a larger file that has, in it's original format more contnent that is not within the php tags. I like to start by giving people the benefit of the doubt

so now you need to find out why $venue is empty. Hint: PHP is very case sensitive...

I don't know why you are constantly closing and opening your php tags. simple_feed_list(get_the_title()); ?>