Muddy_Funster

Quite welcome.

I was just poking fun at @Jacques1 regarding a previous post we debated on. He is an incredible talent, but often comes across more abrasive than helpful so I like to get a jibe in when I can (which is rarely to be fair) Regards "Normalisation" : really it's a problem of scale. When your only talking about a few hundred rows in a dozen or so tables it can be quite difficult to see the justification of why it is one of the most fundamentally important aspects of DB design. However, once things grow - and they always do - it becomes exponentially more apparent why it's needed. Once you start trying to query tables that have senseless column names used in obtuse partial relationships attached to tables with 50-60 columns of redundant data per row holding tens of millions of rows of data named something that is 6 characters long and "made sense at the time" you will quickly be reaching for the revolver. Not only does it make writing queries a new form of self-harm, but it also has a directly proportional impact on performance to the degree that I have seen a DB designed so badly by a third party in MS-SQL Server that queries which should have run in a few tens of seconds crashed out - caused a named pipe timeout triggered by the query taking more than 3 minutes to return a dataset from a five table relationship where the biggest one held a shake over one million records (which is really not much in DB terms). TLDR: YES - Lack of Normalisation Can Break Your App

Possible? probably, and I mean that in the "anything's possible" kind of way. Likely to happen in the real world? No, unless for some crazy crazy reason you use a static salt for all passwords) How to prevent it? Why would you bother? Even if it were to happen, what harm do you envisage? Technically you could put a unique index on the DB column and then request the user try a different password if it throws a duplicate entry error (just don't tell the user why their password doesn't work!). But the chances of the same random salt being generated for the same password the one time another user registers it is infinitesimal (like one times ten to the minus several billion). Of course enforcing a good password requirement will reduce the chance of raw password collisions as well.

@Jacques1 The OP doesn't have the relevant information to to a full and proper DB design. I would rather have stored procedures and BEFORE INSERT triggers for rule checks than a needlessly bloated table structure with arbitrary single-column tables. But I expect I'm about to be schooled in the fact that I'm wrong in taking that approach

PK = Primary Key FK = Foreign Key These are both fundamental parts of database design. What you would do would be to relate between each table to build a structured response. I'll show you the simple one: SELECT tblRecruited.fName AS FirstName, tblRecruited.lName AS LastName FROM tblRecruited LEFT JOIN tblMgtStaff ON ( tblMgtStaff.UID = tblRecruited.recruitedBy ) WHERE ( UID = ? ) That returns all the records that have the recruitedBy field set to whichever ID number you choose to enter as the ?

Sorry, the Edit didn't update the link destination, it was still going to /2/ rather than the /3/ - https://jsfiddle.net/mphur5eq/3/ If that doesn't update just change the /2/ in the address bat to /3/ and you're good to go.

It's just the way the append thing works, You could tweak the JS using callbacks to get the exact order every time, but I just hardcoded the empty form to the right div. https://jsfiddle.net/mphur5eq/3/ that should now do everything that you asked and more: I have included a line that renames the form elements in the right form so that they won't conflict with the ones in the original form, allowing for you to submit them separately.. Still, as @kicken already said, I would love to know why you want to do this in the first place. ::Edit changed the link - previously forgot the part that clears down the existing contents before appendTo() is run.

Updated using clone() with appendTo() https://jsfiddle.net/mphur5eq/1/ as explained here: https://api.jquery.com/clone/

I'm not too fussed about why it's cutting rather than copying, but: https://jsfiddle.net/mphur5eq/ works with dynamic inputs.

That's not a good place to start. That's also not a good way to continue. That said, as a bare minimum, not taking into account any data that I would believe to be pertinent to the process such as dates and reasons for decline etc. and just off the top of my head I would suggest something like this: -------------------------------------------------- tblMgtStaff UID - int, unsigned, auto_inc, PK fName - varchar lName - varchar tblAuthUsers AUID - int, unsigned, auto_inc, PK MID - int, unsigned, FK(tblMgtStaff.UID).Update-Cascade.Delete-Restrict authLevel - int, unsigned, FK (tblAuthLevels.AID).Update-Cascade.Delete-Restrict authParent - int, unsigned, FK(tblMgtStaff.UID).Update-Cascade.Delete-Restrict tblAuthLevels AID - int, unsigned, PK assingedLevel - varchar |Manager/Assistant Manager/Deputy Assistant Manager| tblRecruited RID - int, unsigned, auto_inc, PK fName - varchar lName - varchar recrutedBy - int, unsigned, FK(tblMgtStaff.UID).Update-Cascade.Delete-Restrict preAuthBy - int, unsigned, FK(tblMgtStaff.UID).Update-Cascade.Delete-Restrict finalAuthBy - int, unsigned, FK(tblMgtStaff.UID) .Update-Cascade.Delete-Restrict -------------------------------------------------- That should be enough to work out who works for who, present data based on authorisation level while maintaining branch segregation and trace through all steps from exec to manager. It's not exact, but it should be enough to answer the question. ::Edit to fix quote

@requinix: Yeah, I just wanted to stress the need to establish if the AM has to pre-approve before the M has visibility, or if there was a pool sitting there that both the AM and M could see and that if the M was having a quiet Tuesday they could just bypass the whole AM approval and give someone a job. Also I'm unclear on if it's a pre-auth process if there is a bypass option that the M could use to authorise in the absence of a given AM (thinking long term sick or 3 week vacation kinda thing) or what if any other process would be appointed to this scenario. @ajoo: The DB schema design is a core part to app design and it pulls on aspects, to a greater or lesser degree, of the whole design brief - from the seemingly least significant bit (couldn't resist the pun) of data through to the intended UI. Because of this, answering your question accurately and properly isn't possible with the information that you have given. I appreciate that posting up a complete design brief on a public forum is neither practical nor proper, but in the case here you really do need to go through the whole thing with a fine tooth comb and ascertain everything that you are being asked and then from that information build up the best way to implement the storage schema.

OK, so you explained the scenario, but you didn't give us anything about the context of the data itself. 1> what's the point of AP_AM on DM recruitment if it still requires AP_M anyway? That's illogical. Either the AM can authorise or they can't. 2> what performance data are you talking about? 3> you say in the second paragraph that M can recruit exec's but then later have a condition that they can not. Which is accurate? 4> what information relating to the authorisation process is relevant? e.g. authRequestDate, authRequestUser, authGrantUser, authGrantDate, authDeclineReason etc. From what you describe it's a simple tree structure hierarchy that your looking for, but there are still a couple of ways to build that depending on how much data surrounds each aspect of the process and how relevant that data is to the other data being used.

It's OK, you don't sound ungrateful - condescending, yeah, but not ungrateful. Well, using an unsigned, auto_inc bigint datatype gives you up to 18,446,744,073,709,551,615 possible records. How many more "combinations" could someone need? Actually...what do you even mean by "combinations"? I don't know if we're missing some information or your just not open to the idea that what you are trying to do is not best practice. Even the database system itself uses auto_inc data types to manage it's internal tables and referencing. To be honest, and I'm not trying to be flippant or nasty when I say this, if your heart set on ignoring us and doing it the wrong way then you would be better off talking to someone at that University of yours.

t'internet is an amazing thing if one is prepared to use it : Here and Here - both on page one of a well known search engine - may not be exactly what you are after, but there should be enough code between the two of them for you to hammer out what you need.

Couple of things: 1> your first code block is screaming "Infinite Loop" at me. It may not be for every occurrence but I can't see why you made it a loop at all, you really shouldn't ever run queries inside loops unless you absolutely have to. 2> What's the nature of your ID column and why are you setting it manually? Manual setting of ID fields is a bad idea and can lead to serious (i.e. break the whole system) difficulties when multiple users start using the app at the same time.

Just type "php app builder" into your search engine of choice. You should get plenty of results.

What your asking for is a full end to end application. Something that works right through from the DB data to the page design. Depending on what kind of time you have on your hands you have a couple of options. > Pick something off the shelf to get the job done (like AppGini) - be prepared for hair pulling and a random code injected by the builder. > Commission someone to be built for you, The freelance board is a good start if you have some cash, or else you could try people per hour and hope for someone with both skill and a need to build their portfolio. > Learn a framework and build your own - make sure the framework you pick fits your needs and has good support, something like KendoUI would probably be a decent option. > Build your own from the ground up - just make sure you have stocked up on a lot of coffee and that you have no great love for sunlight, friends or fresh air.

I do take it seriously, and if you were able to break through the mysql user level and get root control over a sever without previously knowing the root user password from passing in an sql command to the mysql application I do genuinely take my hat off to you, hell I'm even impressed to know you can keep interactivity with the server after passing from the sql daemon into the core OS. This merits some duckduckgo-ing.

let's see the findit function

As @Psycho said, you need to sanitise your data before it is stored in the database. You should be using php's trim() on your inputs as part of that process. You can also run the same function directly in mysql to clean up your existing data. Always make sure you have control over your data when you can.

Seems as though your if condition is never returning positive. Remember php is case sensitive. Can you add the following just before the if line and post up the output: var_dump($row['ompShippingMethodID']);

I would hope so too , you should almost always deffer to those with guru status here - it's not something that is given lightly on these boards and I would say that @Jacques1 has clearly displayed he is well versed in this area. All the best with your implementation.

that looks like it should be fine. what's the differences between the actual and expected results?

Could you post up the code as you have it now, the values you are getting for the totals and the values you should be getting for the totals? "way off" isn't really something that we can work with i'm afraid.

I agree, what I do isn't the best way of doing things. That's the primary reason I try to explain my methods as being just that: my methods. I'm not looking to convert others to working the way I do by any means, but information is information - they even teach psychology in this country by spending the first year giving you the wrong information, then spend the next three telling you that it was wrong and why. My putting up information on my methods allows those better than me at this - case in point being you yourself - the opportunity to open up a dialogue that others can see and be part of on why these things are not a good idea, thus providing help and insight. It's just nice when it's done in a positive and constructive way I do what I do because it's the quickest and easiest way to get the results I require within the constraints my workplace puts on me. I'm not a dedicated coder, I don't make that as an excuse - as much as it sounds like it at this point - but I can only do what I can do and no more. If I have to have something live within a time frame then I will assess security in relation to the environment and code to the standard I asses to be necessary. This approach is obviously null and void when applying it to web facing projects.