I'm a newbe I may be missing something. But I have an issue with records getting duplicated in my app. So I created the same CRM app and it does the same thing.
Here's how to duplicate the error:
#1) Load the sample CRM app
#2) Create a new customer and key the Login Name as: julie
You will get a message say you have attempted to create a duplicate
login name. Please choose a different one.
#3) Change the login name to something else like: julie99 (Click Save)
#4) Go to Find Customer, sort by Login Name and you will see the problem. The system created TWO records. One WITHOUT an RECORD NUMBER and one with.
Please advise on how I can fix this or if you need to make a code change on your side.
------------------------------------
QUESTION #2: Is it possible to setup the LOGINNAME field to not be a required field and not create a BLANK login. For example, we would like customer to be able to Login but until we assign them a login name or get there email address the field needs to stay blank. I can't figure out how to do this?
REPORT ERROR doesn't appear to be aborting the rule
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Please advise on how I can fix this or if you need to make a code change on your side.
We cannot reproduce it on our systems. We are using the sample CRM application with MySQL 5.0.18. The second customer with the login name "julie" is not created, whereas the second one (julie99) is. We did exactly the same thing as you described. Are you using the sample application or your own application?
QUESTION #2: Is it possible to setup the LOGINNAME field to not be a required field and not create a BLANK login. For example, we would like customer to be able to Login but until we assign them a login name or get there email address the field needs to stay blank. I can't figure out how to do this?
If you don't want this field to be required just untick the "Value must be provided" checkbox in the definition of the LoginName attribute. I didn't understand the second part of your question. First you are saying that you don't want to create a blank login, then you are saying that you want login to stay blank until it is assigned?
We cannot reproduce it on our systems. We are using the sample CRM application with MySQL 5.0.18. The second customer with the login name "julie" is not created, whereas the second one (julie99) is. We did exactly the same thing as you described. Are you using the sample application or your own application?
QUESTION #2: Is it possible to setup the LOGINNAME field to not be a required field and not create a BLANK login. For example, we would like customer to be able to Login but until we assign them a login name or get there email address the field needs to stay blank. I can't figure out how to do this?
If you don't want this field to be required just untick the "Value must be provided" checkbox in the definition of the LoginName attribute. I didn't understand the second part of your question. First you are saying that you don't want to create a blank login, then you are saying that you want login to stay blank until it is assigned?
Aware IM Support Team
I was having the issue in my own app. I then went into the Help / Sample App on the server and let the system create the CRM app and tryed it. The samething happened. We have MySQL 4.1.16, do you think the problem will go away if we upgrade it? I can load everything on a new machine in the morning and try it with MySQL 5.x if you think that should do it.
----------------------
#2. Regardless of where I try and change the "LoginName", everything is greyed out in the Attribute form. FYI, it is locked for edit and everything else is available.
Sorry about the double talk in my original question. I was making reference to a BLANK/NULL login record being created in the systemuser database by mistake. We need our contact database to allow a blank field because we don't always have a login to assigned a customer.
----------------------
#2. Regardless of where I try and change the "LoginName", everything is greyed out in the Attribute form. FYI, it is locked for edit and everything else is available.
Sorry about the double talk in my original question. I was making reference to a BLANK/NULL login record being created in the systemuser database by mistake. We need our contact database to allow a blank field because we don't always have a login to assigned a customer.
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
I can load everything on a new machine in the morning and try it with MySQL 5.x if you think that should do it.
This will be quite a surprise if it works in MySQL 5.0 and doesn't work in 4.1. If you can easily upgrade please do and let us know.
#2. Regardless of where I try and change the "LoginName", everything is greyed out in the Attribute form. FYI, it is locked for edit and everything else is available.
OK, here is the back door:
1) Open rules of the object for editing to see a list of rules
2) Click on the "Invoke Filter dialog" button in the top left corner of the Rule Editor
3) Tick "Show auto-generated rules" checkbox on the dialog
4) The list of rules should now show more rules - it should include the auto generated rules. Select the rule named "Must provide value of RegularUser.LonginName" and delete it
5) Go to the LoginName attribute and check that "Must provide value" checkbox is now unticked.
This will be quite a surprise if it works in MySQL 5.0 and doesn't work in 4.1. If you can easily upgrade please do and let us know.
#2. Regardless of where I try and change the "LoginName", everything is greyed out in the Attribute form. FYI, it is locked for edit and everything else is available.
OK, here is the back door:
1) Open rules of the object for editing to see a list of rules
2) Click on the "Invoke Filter dialog" button in the top left corner of the Rule Editor
3) Tick "Show auto-generated rules" checkbox on the dialog
4) The list of rules should now show more rules - it should include the auto generated rules. Select the rule named "Must provide value of RegularUser.LonginName" and delete it
5) Go to the LoginName attribute and check that "Must provide value" checkbox is now unticked.
Aware IM Support Team
Thanks for the LoginName fix. Thats working great now.
------------------------------------------------------------------
Now on to the original issue with the US (MM/DD/YY) Format. I did a fresh install of MySQL 5.x and I downloaded AwareIM and installed it on a new Windows 2000 server.
I installed the sample CRM app and tested the same as above. Everything worked fine. No Problems on the new install w/MySQL 5.x and AwareIM.
So I upgraded my MySQL v4 to the same v5 and I rebooted and tryed my app and had the same issue. I then EXPORTED the SAMPLE CRM app from the new machine that was working.
I created a new app on my server I've been having this issue with and IMPORTED the APP that was working fine on the new machine. Tryed it and had the SAME PROBLEM as before.
So whatever this is its not the APP and its not MySQL.
I also noticed if I have a DATE field in the app on one of the forms it screws it up as well. So its not just the import. And I just realized that the machine I'm having an issue with is Windows 2003 Server. And the one that is working is Win2000. Could this have anything to do with it?
Could this be a Win 2003 issue with the (mm/dd/yy) US date format? I've spent the last 6 1/2 hours on this issue and can't figure it out to save me.
Any additional suggestions?
------------------------------------------------------------------
Now on to the original issue with the US (MM/DD/YY) Format. I did a fresh install of MySQL 5.x and I downloaded AwareIM and installed it on a new Windows 2000 server.
I installed the sample CRM app and tested the same as above. Everything worked fine. No Problems on the new install w/MySQL 5.x and AwareIM.
So I upgraded my MySQL v4 to the same v5 and I rebooted and tryed my app and had the same issue. I then EXPORTED the SAMPLE CRM app from the new machine that was working.
I created a new app on my server I've been having this issue with and IMPORTED the APP that was working fine on the new machine. Tryed it and had the SAME PROBLEM as before.
So whatever this is its not the APP and its not MySQL.
I also noticed if I have a DATE field in the app on one of the forms it screws it up as well. So its not just the import. And I just realized that the machine I'm having an issue with is Windows 2003 Server. And the one that is working is Win2000. Could this have anything to do with it?
Could this be a Win 2003 issue with the (mm/dd/yy) US date format? I've spent the last 6 1/2 hours on this issue and can't figure it out to save me.
Any additional suggestions?
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Now on to the original issue with the US (MM/DD/YY) Format
The original issue in this thread seems to be the issue with duplicates and has nothing to do with the date format. Or are you talking about the invalid date format during import issue that you reported in a different thread? If so, then you need to download the latest build (845) that has a fix to this problem.
Tryed it and had the SAME PROBLEM as before.
Are you talking about the duplicate issue now? Are you saying it happens on Windows 2003 and not on Win 2000? If so, it must be a MySQL problem with transactions on Win2003. Can you try Derby on Windows 2003?
I also noticed if I have a DATE field in the app on one of the forms it screws it up as well.
In what way does it screw it up?
Could this be a Win 2003 issue with the (mm/dd/yy) US date format?
Again I'm not sure what issue you are referring to?
The original issue in this thread seems to be the issue with duplicates and has nothing to do with the date format. Or are you talking about the invalid date format during import issue that you reported in a different thread? If so, then you need to download the latest build (845) that has a fix to this problem.
Tryed it and had the SAME PROBLEM as before.
Are you talking about the duplicate issue now? Are you saying it happens on Windows 2003 and not on Win 2000? If so, it must be a MySQL problem with transactions on Win2003. Can you try Derby on Windows 2003?
I also noticed if I have a DATE field in the app on one of the forms it screws it up as well.
In what way does it screw it up?
Could this be a Win 2003 issue with the (mm/dd/yy) US date format?
Again I'm not sure what issue you are referring to?
Aware IM Support Team
Sorry for the screwed up post. I was working on two different issues.
The date format is fixed with the latest update. Although, fyi I believe if you type a date format as mm/dd/yy under the attribute it still happens. If you type or select MM/dd/yy it works? I'm using MM/dd/yy so everything fine here. Thanks
==============================
The duplicate is on Windows 2003 and not Windows 2000 and if you leave out all the bs about the date I put in the previous post and replace it with this duplicate issue. The duplicate issue is what I was testing and that's not working on Win 2003.
Thanks and again, sorry for the crazy post.
The date format is fixed with the latest update. Although, fyi I believe if you type a date format as mm/dd/yy under the attribute it still happens. If you type or select MM/dd/yy it works? I'm using MM/dd/yy so everything fine here. Thanks
==============================
The duplicate is on Windows 2003 and not Windows 2000 and if you leave out all the bs about the date I put in the previous post and replace it with this duplicate issue. The duplicate issue is what I was testing and that's not working on Win 2003.
Thanks and again, sorry for the crazy post.