I'm no PHP expert, so forgive my ignorance.

If you test in a basic manner, rather than by using AJAX, what happens? By using your browser's inspector, you can see that doing:

$.ajax({
  url: "my_service",
  data: {f_date1: "yesterday", t_date1: "today"},
  success: function(msg) {
    console.debug("yay")
  }
});

will result in a GET request like this:

my_service?f_date1=yesterday&t_date1=today

If you paste that into a browser's URL bar (or better yet use something like HTTPie or Postman), you can make sure that you can access the query string properly. Once you know that works, and you know that jQuery's .ajax method does the same thing, you'll have a much better chance at solving your problem.

Read More

Is reporting the only reason you need this number? If that's the case, remove it from your application and add it to your report. In PostgreSQL you an use a window function for this, but in MySQL do something like this. Imagine you have a table of names:

create table people (id int primary key auto_increment, name varchar(20)) ;

insert into people (name) values ('John'), ('Paul'), ('George'), ('Ringo');

Now, you want them numbered by something other than the id:

select
  (@i := @i+1) as number,
  id,
  name
from people, (select (@i := 0)) j
order by name desc;

    | number | id |   name |
    |--------|----|--------|
    |      1 |  4 |  Ringo |
    |      2 |  2 |   Paul |
    |      3 |  1 |   John |
    |      4 |  3 | George |

There's a better example here.

Providing your query is constructed properly and is only selecting records from a particular day, and your results are ordered, your results will be the same every time. Plus, your application is simpler, you have fewer columns and you won't run into transaction-related bugs.

Read More

What probably happened is that your customer created an order, then while the above code was running they created another. As you're using max to work out which number to allocate and you've not yet saved the first record, both have the same id. Without knowing your transaction isolation level I can't say why your sequence looked correct.

Rule of thumb, for automatically generating numbers, use a sequence (known as auto increment in MySQL). Also, if your ids are meant to be unique, consider making that column a primary key; if not use a unique index.

Read More

Incidentally, in my earlier post, I used Rails-esque route notation :group_id and :membership_id. In case it's not obvious, that's where your identifiers would go, so the actual path would be /groups/1/memberships/3 (or if you prefer slugs, /groups/admin/memberships/joey)

Read More

Perhaps what I am doing, however, is creating a new membership record?

This is correct, but when you're posting to /groups/memberships, to which group are you adding a member?

I'd expect to see something more like this. Of course, you don't need all of these actions (i.e. updating a membership, which is probably just a record in a link table, might not be necessary) but it's obvious at every point what each action does.

GET    /groups/                                     get a list of all groups
POST   /groups/                                     create a new group
GET    /groups/:group_id                            get an individual group :group_id
PUT    /groups/:group_id                            replace group :group_id
PATCH  /groups/:group_id                            modify group :group_id
DELETE /groups/:group_id                            delete group :group_id

GET    /groups/:group_id/memberships                get a list of members for group :group_id
POST   /groups/:group_id/memberships                create a new membership for the group (i.e. add a member)
GET    /groups/:group_id/memberships/:member_id     get an individual membership :member_id for group :group_id
PUT    /groups/:group_id/memberships/:member_id     replace membership :member_id
PATCH  /groups/:group_id/memberships/:member_id     modify membership :member_id
DELETE /groups/:group_id/memberships/:member_id     remove membership :member_id from group :group_id

Also, it would appear that your Markdown implementation doesn't support tables! :)

Read More

I suggest you use the HTML Agility Pack rather than attempting to use loops, counters and .IndexOf. It will allow you to use XPath which will be more efficient and require less complex code to achieve. Or, if you're doing this as a one off, copy it into a .csv file and use the standard tools.

Also, pasting a wall of unformatted HTML isn't going to help anyone. Either link to a gist or use the 'Code' button above to make it somewhat readable. If it still looks like a wall of text, use html tidy first.

Read More

I doubt it's your query that's slow. What happens if you simply run the query select * from Doopgegevens; in a shell? For ~10k rows, providing your table is holding 'normal' data (and not base64 encoded movie files or something) it should be fast. If it is fast, try changing your data list to only use a subset of your table's columns, which will indicate if that's where your performance problem is.

Read More

I've made a couple of lengthy posts over the last couple of days and have noticed a few bugs with the editor. Nothing show-stopping but some make the editing process more difficult or some content vanish! (I added the 'nerd' Emoji in one of my posts, it saved without errors but all subquent content in the post was missing!). Rather than me add them here, is there a tracker somewhere so they can be categorised, verified and dealt with? If there is, I'm happy to post detailed steps, screenshots, even animated gifs if that gives whoever will be looking at it a better chance :)

Read More

It sounds like you aren't working to the strengths of the database. MySQL, unlike Oracle, PostgreSQL etc doesn't support arrays, and searching on text is unlikely to be optimal.

I don't know the context of the original query, so it's difficult to suggest a solution, but it could be something like this:

 Tags:
 - id: 1
   name: Programming
 - id: 2
   name: Databases
 - id: 3
   name: Web Development
 - id: 4
   name: Floristry
 - id: 5
   name: Kids TV

 Posts:
 - id: 1
   name: Making pages faster
   tags: [1, 2, 3]
 - id: 2
   name: CBeebies top ten
   tags: [5]

So, to find all posts about Web Development you'd look through all of the posts, filtering on the tags field for the inclusion of 5. In PostgreSQL, using the array type, we'd do something like this:

select * from posts;
┌────┬──────────────┬─────────┐
│ id │     name     │  tags   │
├────┼──────────────┼─────────┤
│  1 │ CBeebies     │ {5}     │
│  2 │ Fast Website │ {1,2,4} │
│  3 │ Programming  │ {4,6}   │
└────┴──────────────┴─────────┘
(3 rows)

Time: 0.282 ms
peter=# select * from posts where tags @> '{5}';
┌────┬──────────┬──────┐
│ id │   name   │ tags │
├────┼──────────┼──────┤
│  1 │ CBeebies │ {5}  │
└────┴──────────┴──────┘
(1 row)

That's fine, but that doesn't give you the benefits of using a relational database. What if someone deletes the Kids TV tag from the tags table? Well, our arrays (or strings full of comma separated values) will point to nothing. That's precisely what we ...

Read More

Comments
nice explanation, thanks for sharing!

It would appear that the leak is available; the reason I logged in after quite a break was that I received an email from haveibeenpwned.com telling me that:

You've been pwned!
You signed up for notifications when your account was pwned in a data breach and unfortunately, it's happened. Here's what's known about the breach:

Email found: xxxxxxxxx@gmail.com
Breach: DaniWeb
Date of breach: 1 Dec 2015
Number of accounts: 1,131,636
Compromised data: Email addresses, IP addresses, Passwords
Description: In late 2015, the technology and social site DaniWeb suffered a data breach. The attack resulted in the disclosure of 1.1 million accounts including email and IP addresses which were also accompanied by salted MD5 hashes of passwords. However, DaniWeb have advised that "the breached password hashes and salts are incorrect" and that they have since switched to new infrastructure and software.

Read More

Remember that UNION (and its cousins INTERSECT and EXCEPT) essentially require each of the provided queries to be run separately and the results collated. In this example (using PostgreSQL, but the same applies in MySQL), we can see exactly what's happening.

I have a small table with some users and their favourite colours:

peter=# select * from users;
┌────┬─────────┬──────────────────┐
│ id │  name   │ favourite_colour │
├────┼─────────┼──────────────────┤
│  3 │ Francis │ blue             │
│  4 │ Toby    │ blue             │
│  1 │ Joey    │ red              │
│  2 │ Dwayne  │ purple           │
└────┴─────────┴──────────────────┘
(4 rows)

Time: 0.400 ms

Now, let's say we want all users with a favourite colour of blue or red; if we use a UNION the following happens:

peter=# explain select name from users where favourite_colour = 'blue' union select name from users where favourite_colour = 'red' ;
┌───────────────────────────────────────────────────────────────────────────┐
│                                QUERY PLAN                                 │
├───────────────────────────────────────────────────────────────────────────┤
│ HashAggregate  (cost=35.33..35.39 rows=6 width=58)                        │
│   Group Key: users.name                                                   │
│   ->  Append  (cost=0.00..35.31 rows=6 width=58)                          │
│         ->  Seq Scan on users  (cost=0.00..17.62 rows=3 width=58)         │
│               Filter: ((favourite_colour)::text = 'blue'::text)           │
│         ->  Seq Scan on users users_1  (cost=0.00..17.62 rows=3 width=58) │
│               Filter: ((favourite_colour)::text = 'red'::text)            │
└───────────────────────────────────────────────────────────────────────────┘
(7 rows)

Time: 3.868 ms

As you can see, the query plan involves

  • two sequental scans (Seq Scan) that each perform a Filter,
  • an Append operation which is actually performing the UNION,
  • plus Group Key and HashAggregate steps, from which the resulting recordset can be ...

Read More

[QUOTE=red_ruewei;1694533]thanks for reply.
I try something like this to read record with range month and year.
Example from June, 2011 to June 2012
[CODE]
Select * from table where (YEAR(date1)>='$year1' AND MONTH(date1)>='$mon1') and (YEAR(TKH_date1)<='$year2' AND MONTH(TKH_date1)<='$month2')
[/CODE]

i had test this. And run separately.
[CODE]
(YEAR(date1)>='$year1' AND MONTH(date1)>='$mon1')
[/CODE]
For above code it run smoothly

[CODE]
(YEAR(TKH_date1)<='$year2' AND MONTH(TKH_date1)<='$month2')
[/CODE]
But for this code, it fail....

TQ[/QUOTE]

Fails why? What error? What variables? Also, by calling YEAR(blah) you're going to bypass your indices and your query will be slow. Something like this is better and will work.

[code=mysql]
SELECT * FROM table WHERE date_data >= '2011-06-01' AND date_data < '2011-07-01';
[/code]

Read More

If you have a lot of internal software that utilises Exchange, Google Business Apps may not be what you're looking for. Depending on what this software does it may not work at all with Google Apps or you may need to change the way you work.

I have used Google Apps with the last company I worked at, though, and it is fantastic. You get the benefit of having everything 'looked after' hardware-wise by Google's team, the best webmail client available, POP3/IMAP access if required, excellent calendar, tasks, office apps, contacts directories etc.

Read More

Your text example doesn't really show how the script you provide works. Here's what you are probably after though - this could be a bit more robust but in this state it's clear:

[code=ruby]

!/usr/bin/env/ruby

first get the name

puts "Enter your name"
name = gets

now get a number, to_i returns the entered string (eg "5" to an integer eg 5)

puts "Enter a number"
number = gets.to_i

times is a method on integer, we can use it to iterate through the block

number.times do

print the name

puts name
end

[/code]

Read More

KDE is not supported because this is a LTS release; KDE 4 will be brand new when Ubuntu 8.04 is released and there is no guarantee that the KDE guys will still be writing security updates etc for KDE3.x releases in 3 years time.

It simply does not make sense to offer LTS on either a 'bleeding edge' KDE release or one that may not be actively developed soon.

Ubuntu has a Gnome focused release schedule; this is just a case of bad timing.

Read More