requinix

Actually I was thinking something more... precise. What does a SHOW CREATE TABLE whatever output, and what is the actual SQL for those queries? While I'm here, take each of those queries and execute them with an "EXPLAIN" in front. So EXPLAIN SELECT.... That'll output a table which explains how the query executes and can indicate where potential problems are with (though it's not easy to read if you're unfamiliar with it).

A blob of data (like JSON) vs. relational data shouldn't be a question of performance. It's about use cases. 3M rows isn't actually that large. Well, relative to what other people and companies do with it. What's the structure of the table and what kinds of queries are you running on it that are taking so long?

"Oh I see he's reading the topic. I know he'll reply to this so I'll just wait a bit... (refresh) No, he hasn't replied yet. I'll give him more time... (refresh) Still no... (refresh) Alright, it's been an hour, I have this reply ready so I'll just copy and paste it in here, and voila! there's my po-- DAMMIT" context? I posted a reply just after Barand saying the same thing so I hid mine

I don't follow. You can't tell what someone is doing on another website...

Both of those are already friendly. I would say the "before" one is actually better than the "after".

Option 3: Treat the contents as Javascript code and not JSON. JSON is inherently valid Javascript so anything already existing is still good, and you just consider the string to be (shudder) eval-uatable code. var evaluated = eval("(function() { return " + value + "; })()");At what point does the color need to be (re)evaluated? Is the theme data known server-side too?

We can definitely tell you better ways to do this, but to tell you why it doesn't work for your friend we would need to know what the error message is. He is trying to upload a valid image, right? JPEG/PNG no more than 20MB? 10 is a magic number for the line in the file containing the value of $data.= sizeof($_FILES['file']['name']).'-images'."\r\n";from the earlier code.

a) If the table structure matches up with the CSV exactly - and the use of columnN names suggests it is - then you don't need to specify the columns at allb) If the table does not match up, and if PHP can access the CSV file, then it can determine the columns dynamically: open the file, read the header row, count how many columns there are c) If the table does not match up and PHP can't read the file, then you would have to put that configuration somewhere. Continuing with the INI example, column[0] = id column[1] = column1Throw in the fact that you can read the table structure at runtime and you can probably figure out everything you need to know without having to resort to that third option. But the point is that it could, so you'll need to account for that. You could set up a sort of "default email list" and then override that as needed. But those columnN names aren't so great. Can you change those? Make them mirror what's in the CSV, even if that means having to `-quote them?

Exactly how much repetition is there? Are all the scripts the same except for the input file and destination table? Are the email messages the same, or how do they vary? The "best" case would be that everything but the file and table are the same. You could then get rid of all the script except for one (since they'll all work the same way) and find a way to provide the missing information: my choice would be an INI file like [arbitrary_label] source = DataImport/sourcefile.csv database = mydatabase table = mytable email[] = "Mail 1 <[email protected]>" email[] = "Mail 2 <[email protected]>" email[] = "Mail 3 <[email protected]>"and you invoke the PHP script with the "arbitary_label" argument. @C:\PHP\php.exe C:\path\to\script.php %* Command: C:\path\to\batch-file.bat Arguments: arbitary_label Load the appropriate data into variables and pass them around as needed. The worst case is the scripts are all totally different. Which I doubt is what you're working with. So reality is probably somewhere between the two.

Look just for a case-sensitive "$Fields". It has to be in there somewhere... but if it wasn't then that would explain why the value is null and instead you have to figure out what value should be getting used in there. But it feels like that code is all broken anyways and what you're doing is the correct solution. Yup. Generally an associative array is better to work with (you can reference fields by name) but sometimes the indexed or hybrid versions are more useful to have in code. If the code only needs the primary key then yeah, querying the indexes would be better. No and yes. There can only be one primary key but it could have multiple columns (be a composite key). So in general you would need to get all the rows and possibly reassembly the key using the [seq_in_index]. Which you need to do anyways because of other non-primary keys. ...then why are you doing it? It is quite wrong: in_array() checks if a value is in an array (both of those arguments are strings) and returns true or false accordingly (you're comparing the return value with the key name). All you need is a simple comparison: if ($Array['Key_name'] == 'PRIMARY') I'm not even sure what you're trying to do there, but I'm pretty sure the function is supposed to return an array of key names. Right now you're making an array of arrays containing '0's and '1's. If the key is part of the primary key then $primary[] = $Array['Column_name'];That's it. $primary[] = will add a new value to the array, and that value is the [Column_name]. Using that echo for debugging is fine but it would be more helpful if you outputted the column name at the same time. Like echo $Array['Column_name'], " is in the primary key\n";

Either you shouldn't care about what day is what, or you need to find out (or decide) how the business itself answers the question. Like I said, it's probably about the start date: if I work Sunday 10pm to Monday 6am then I would say my "Sunday" shift was 8 hours long. Maybe I'm not understanding what is so confusing about this?

$Fields being empty is one problem, but you haven't posted enough code for us to figure out why. The other is that $ARR is an associative row. That means there is no [0] or [3] and instead, as you can see in the print_r() output, it has a [Field] and [Key]. So if ($ARR["Key"] == "PRI" && in_array($ARR["Field"], $Fields)) { $primary[] = $ARR["Field"]; }You also need to initialize $primary to an empty array for the case of tables that don't have primary keys. Otherwise your function will return null.

Not sure what you want for this. If you want simplicity then a database isn't the answer. I'd go for a flat file, like INI or JSON or even just text files with one email per line. Mock up the email in a single HTML file, put quick little placeholders (like "{{date}}") for any information that needs to be inserted, then file_get_contents() and strtr() with an array to get the final result. "Tags"?

That only holds for overnight shifts. Are you specifically targeting only those and want to deliberately prevent your system from being compatible with daytime shifts? What about a case where an overnight worker has an emergency and leaves during the same day? Assuming logoff is the next day will automatically credit the person with 24h more than they should, not to mention potentially conflict with a shift the next day. Depends. What does the business think? It's probably determined based on the start date: "if start date is within month then sum(end date - start date)." So you want duplicate IDs? Don't. More appropriate would be to store login and logoff in the same row.

Then they need to know about that. But many projects like Bootstrap and jQuery use the MIT license which allows for virtually any usage, including resale, provided the copyright blocks are left alone and the warranty statement (or more precisely the lack of warranty) is included with a copy of the license. So this likely will not be a problem. I assume the issue is that the "often used code" is your own personal license-able code which you've reused with the application? a) You treat those parts as "third-party library" code, and add it to their application by granting it/the client with an appropriate license - eg, one that would grant them the ability to share the code and/or application. Like the MIT license. You can do so specifically for this client without affecting licenses granted elsewhere. b) You rewrite the affected parts so they're no longer your own personal code. Do not do "implied" licenses. It should always be written in the contract, and when it isn't it's generally legally assumed that the product of your work under their employment is automatically their property.

Don't store login hours. Store login timestamps. Full DATETIME/TIMESTAMP values. And if you have each work period storing a login/logout pair then you can SUM the diffs.

They're not sure? That's a problem.

Well, what do they have available? mssql? SQLSRV? ODBC?

Ha, yeah, I just noticed what forum this is in... So you need the current page's query string? Try document.location.search (which includes the question mark).

Use parse_url with PHP_URL_QUERY to grab just that part.

Does too. https://3v4l.org/v5Cdt

Try $THROWOUT_PAYED_FULL = (float)($BUYEDFULL . '.' . $BUYEDHALF);

We have no idea what that code is or what it does. If I search for "get_image_for_designment" then all I find is a bunch of other posts from you on other sites (including at least four posts on StackOverflow for this one problem).

"Foreign key constraint is incorrectly formed" I feel like I've been snippy lately? Maybe I should step away from the forums for a while.