NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: CyberFerret on September 12, 2011, 03:08:37 AM
-
I've just come across a strange problem that I hope someone here can help with. I am not sure if it is a NetTalk WebServer problem, or an ODBC driver problem, or a MySQL problem?
In short: We have a NetTalk web app that talks to a back end MySQL database via ODBC. Standard template NetWebBrowse -> NetWebForms. Within the database, we are using VARCHAR(64) fields as the unique ID, and I am generating a GUID using the IceTips tools to prime these ID fields when a new record is added.
All seems to be going OK, and when I check the MySQL database, the GUID's are being saved nicely, along with all the other data.
But when testing, I find that when I edit some of the records, and click the 'Save' button, I am getting a 'Duplicate Key Found PRIMARY --> CLI:ID' which is happening in the CheckForDuplicate routine.
PRIMARY is the name of the key, which only has CLI:ID as the only unique, primary key field in it.
Wierd in that it only happens on SOME records, not all. Is this a bug in the ODBC driver, (I am using v3.51) or with MySQL?
Because I am generating long GUIDs manually, I don't think we will ever have the occurance of a duplicate value in the database, so to circumvent this, I have just put an EXIT at the top of that routine however I am nervous that this might break something else?!? Did I do the right thing?
Thanks!
Devan
-
nothing useful springs to mind Devan.
However if you are suing a random Guid I think the duplicate check is probably superfluous.
cheers
Bruce
-
I don't use MySQL but I had similar problems before. Look in the table for a record with a blank CLI:ID - you may be trying to add another record with a blank CLI:ID without knowing it.
Thys
-
Thanks Bruce & Thys,
Yeah - this one has got me stumped. Thys - I have scoured the database. There are no blank ID's there at all. The problem NEVER comes up when adding a new record - only when CHANGING an existing one...and always only on certain records.
The problem doesn't 'move around'. It is the same 4 or 5 records in a set of 20 that constantly refuse to save.
In any case, I did a forced EXIT out of the CheckForDuplicates routine, and things still seem to work well, so I will keep my fingers crossed and go live... ! :o
Cheers,
Devan