Non-object error with query, yet returns results

  • (2 Pages)
  • +
  • 1
  • 2

18 Replies - 1018 Views - Last Post: 16 May 2013 - 04:31 AM Rate Topic: -----

#16 T'Shaunik  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 31
  • Joined: 06-February 12

Re: Non-object error with query, yet returns results

Posted 15 May 2013 - 04:05 PM

A potential problem I just realized with the INSERT/UPDATE. Can the duplicate key be the condition that BOTH accountNum AND publisher match?

The problem with the software I'm integrating this with is that accountNum can't be a unique key because there can be (and I have found about 20 cases so far, with many more likely later on once I'm past development) duplicate accountNum's, hence why I'm querying it against both accountNum and publisher because I had some information get overwritten using the accountNum as UNIQUE.
Was This Post Helpful? 0
  • +
  • -

#17 andrewsw  Icon User is online

  • Fire giant boob nipple gun!
  • member icon

Reputation: 3241
  • View blog
  • Posts: 10,875
  • Joined: 12-December 12

Re: Non-object error with query, yet returns results

Posted 16 May 2013 - 01:51 AM

The documentation states that this method works with a duplicate in either the primary key or a unique index, so I assume that either of these could be compound. Have you set the combination of those two fields as either primary or unique? If so, then you could proceed to build some test data.

However, this is just a convenience method and you could equally well use separate steps:

Create a query to retrieve records (or count them) with the accountNum and publisher;
If there are no records returned then perform an insert, otherwise perform an update.
Was This Post Helpful? 0
  • +
  • -

#18 andrewsw  Icon User is online

  • Fire giant boob nipple gun!
  • member icon

Reputation: 3241
  • View blog
  • Posts: 10,875
  • Joined: 12-December 12

Re: Non-object error with query, yet returns results

Posted 16 May 2013 - 01:56 AM

If the accountNum should be primary then the best long term solution would be, IMO, to insist that they are unique! Or to have some procedure in place to intercept duplicates and substitute (perhaps in an additional column) a unique value.
Was This Post Helpful? 0
  • +
  • -

#19 T'Shaunik  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 31
  • Joined: 06-February 12

Re: Non-object error with query, yet returns results

Posted 16 May 2013 - 04:31 AM

View Postandrewsw, on 16 May 2013 - 08:51 AM, said:

The documentation states that this method works with a duplicate in either the primary key or a unique index, so I assume that either of these could be compound. Have you set the combination of those two fields as either primary or unique? If so, then you could proceed to build some test data.

However, this is just a convenience method and you could equally well use separate steps:

Create a query to retrieve records (or count them) with the accountNum and publisher;
If there are no records returned then perform an insert, otherwise perform an update.


I figured out last night that I can make a compound primary key, so I added publisher to the primary key, so now it uses BOTH of those for the primary.

The problem that prompted this thread is I had a query that retrieved accountNum and publisher, but the query that then looked for those records was getting the weird problem that I've been dealing with - giving an error when doing bind_param (or bind_result - if I took away the necessity of the bind_param), yet had no error number or message to print out, and I was clearing out a variable, which showed that despite the error/non-error it was getting, it was still returning the correct accountNum. And with the code that atli suggested, it now says the query is empty, even though the php is printing out the query being sent. I think I'll try scrapping that whole section of code (again) and see if creating it from scratch will get rid of the weird errors.

View Postandrewsw, on 16 May 2013 - 08:56 AM, said:

If the accountNum should be primary then the best long term solution would be, IMO, to insist that they are unique! Or to have some procedure in place to intercept duplicates and substitute (perhaps in an additional column) a unique value.


The people I'm working with are either unwilling or unable to make those changes. The software they have is literally about 30 years old. I've noticed in working with it that the naming conventions for stuff has changed a lot, and the database they have has many fields (about 20 out of 51) for each record that are simply marked as unused and "optional".

I think the solution is having the accountNum and publisher fields form the compound primary key and always make sure it's checking against both in queries. I thought about intercepting duplicates and changing them, but that would overly complicate things as the one absolute I was given (and knowing the situation), was that there will not be duplicate accountNum's for a given publisher.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2