The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
| |
|
Re: Fields saving but not displaying
Posted: 11 Dec 06 10:34 AM
|
fiogf49gjkf0d Lou,
Are those accounts owned by the people that are modifying the missing fields? I have had this happen before in this instance when they were not.
Michael |
|
|
|
Re: Fields saving but not displaying
Posted: 11 Dec 06 11:11 AM
|
fiogf49gjkf0d The people who modify the missing fields are usually not the owners of the accounts. However, this problem does occur for account owners and the ADMIN user as well. |
|
|
| |
|
Re: Fields saving but not displaying
Posted: 13 Dec 06 2:19 PM
|
fiogf49gjkf0d Usually this only happens when a control isn't bound properly. That's SLX 101 type stuff that I'm sure you've covered.
The only other thing it could be is a data problem. I've had an issue that was produced due to an upgraded database (or possibly the DTS import that occured after). The problem was float fields in 5.2 would show something like 6.4999999999999 instead of 6.5. SalesLogix rounded it properly but whenever I would try to enter ANY DATA into the field, the ENTIRE RECORD would not commit. Needless to say this was a big problem because it didn't affect every record or every field and people assumed the data changed when it in fact did not.
I solved the problem externally by creating a RecordCopy() function, which does nothing more than gets an ADO recordset of the existing data, create a new record with a new primary key, then copy the existing data into it. Something in this process fixed the issue but I have no clue what that is exactly. It could be that ADO forced the float data to round up. If that was the case, I should have been able to update the existing record with the correct value. If memory serves me this didn't work (we're talking 3 yrs ago now) but that could be because I was trying to do it in the client versus handling it on the SQL backend.
This originally happened on v6.1 so it's possible that it was an OLEDB quirk that got fixed in a later version. I'd love to figure out what the cause was exactly though because there's no guarantee that our database is free. |
|
|
| |
|
Re: Fields saving but not displaying
Posted: 13 Dec 06 3:37 PM
|
fiogf49gjkf0d Okay that narrows things down.
I assume these are all custom fields in custom tables? Are they strictly custom or do some of them apply to say Account_Extension or other tables off Account? Is there any consistency among them? Meaning does this only happen when you're editing an account, but not with an opportunity? What about strictly custom controls, like those found in Data Forms accessable in grids? Does this happen consistently or is it intermittent?
The keyword here is "pattern". Find it, and it'll likely lead to the problem.
Now I'll throw a monkey wrench in the mix. What you refer to as "saving" is caching done by SalesLogix controls. The record isn't saved in the database because if it was, navigating back to the record should give you the database value. This is unlike unbound controls, which retain the last value regardless of record because the data manager doesn't update the control with the database value.
You should check the Event Logs of your server as well as Documents and Settings\All Users\Application Data\SalesLogix\Sync for SyncErrors.txt. I doubt it'd get to the sync log but it's worth a check.
If I had to guess, I would say something in the strings are what is causing it not to save. Are users copying data? Copy/Paste sometimes introduces artifacts that SQL might not be able to handle but appear normal in the controls. |
|
|
|
Re: Fields saving but not displaying
Posted: 13 Dec 06 6:07 PM
|
fiogf49gjkf0d Lou,
I think the SLXProfiler.exe wasn't introduced until 6.2.3, but I could be wrong. If you have it, it should be installed in the SalesLogix folder. If you have it and run it, does it show anything unusual?
If you don't have it, does a SQL Server trace show the data ever getting to the DB? I don't know if that'd be helpful, but if you can use the SLXProfiler, that might. I've had it show me stuff that the provider didn't like...
Jeff
|
|
|
|
Re: Fields saving but not displaying
Posted: 14 Dec 06 8:48 AM
|
fiogf49gjkf0d Lou,
Do you have any code to enable or disable certain fields once the form is refreshed? I had a similar issue recently where when i changed the status of a pik list, I had code fire to enable/disable fields based on the new value. But this wasn't working and it seemed to be using the old values (maybe from the db?) and everything looked like it was blank but it had in fact saved to the db. I never really got to the bottom of the problem but i added a form.post and form.refresh before the other code fired and it seemed to remedy the issue.
BTW this was in 6.2.4
Zeph |
|
|
|
Re: Fields saving but not displaying
Posted: 15 Dec 06 6:50 AM
|
fiogf49gjkf0d Originally posted by Lou
v6.2.2.1045
Has this ever happened to anyone else? I have a form with various controls: text boxes, pick lists, check boxes, and lookup edits. All of them are data-bound. Data displays perfectly for many accounts. However, some or none of the data displays on other accounts, yet the data does exist and is saved within the database. When a user enters information into these "problem" fields, the information will save (after clicking the "Save" icon, refreshing, or navigating to another record), but it will immediately disappear afterward.
Ideas or suggestions anyone?
|
|
Are the fields in question part of "secured tables" (Tables that have a SECCODEID field)? If so, you may find that the datablobs in ALL (or some) of the SecProfile records are too short.
--
rjl |
|
|
|
Re: Fields saving but not displaying
Posted: 22 Dec 06 9:24 AM
|
fiogf49gjkf0d It's been a while, but I'm back with an update! I still have the same problem. Here is some clarification on some things in case anyone was still interested:
-There was no clear pattern. This seemed to happen at random on some accounts and not others.
-SQL confirmed that the data was saved to the database. However, the data would disappear from view immediately after clickinig the "Save" icon or refreshing (from the "View" menu or with F5.)
-Users are typing in new data, not copying and pasting.
-This is on a simple data entry form. There is no code to enable or disable certain fields.
-These are custom fields in custom tables that function just fine in other places.
With that said, we have actually decided to roll back to a previous version. Sadly, I'm giving up on this for now, but it's cool...I guess... 
I thank everyone again for their time and attention! |
|
|
|
Re: Fields saving but not displaying
Posted: 23 Dec 06 5:21 AM
|
fiogf49gjkf0d I know EXACTLY why this is !
Go to Tools | Options and on the last page press the Restore Notifications box. Next, do what you did above. Notice you will get a dialog that prompts to save data - you must ensure you say Yes to this (and, optionally, never prompt again).
You will now find it works fine. Even if you rollback you will still have the same issue !
PS The issue is simply because, in the past, someone said No to this prompt. So, when SLX does a forced commit with F5 (and for an unknown reason) you are getting the Save Data Prompt. Of course, as you hid the dialog with No as the default then SLX is rolling back the change (as designed). |
|
|
| |
|
Re: Fields saving but not displaying
Posted: 24 Dec 06 10:02 AM
|
fiogf49gjkf0d Absolutely, the no. 1 reason for data being stored but not displaying for some Accounts but not others is......
INNER JOIN to another table (Contact, Address are the biggest culprits) and the row doesn't exist.
SLX enforces the JOINDATA joins.....if you don't have a Contact, Address, or whatever and you have an INNER JOIN in your databound fields the data exists but the data will not be displayed.... this could be a field that you have added to the form, and have an incorrectly formed Local Join (INNER) on the field.....
It's bad enough that the Account will show up in a Group......but when you double click on the group row and go to the detail there is nothing displayed.
And that, RJL, is SLX 101.
RJ Samp |
|
|
| |
|
Re: Fields saving but not displaying
Posted: 27 Dec 06 7:29 AM
|
fiogf49gjkf0d All,
Thanks for still trying to help with the problem, but I had already covered the latest suggestions.
Mike, resetting the prompts was never the issue. Regardless of the prompt, users can save the data with normal methods.
RJS, there is nothing wrong with the joins. The data form only uses fields from the base table.
My problem never existed in the previous version of the form, so I'm rolling back. This has proven to be the best option, because I made a few improvements and things are working as they should now (better than the form with the saving/displaying problem!) Again, I thank everyone for well-advised input. |
|
|
|
Re: Fields saving but not displaying
Posted: 27 Dec 06 8:24 AM
|
fiogf49gjkf0d Lou, Forgive me if you have already checked this or said this...
The data you are updating is it into a custom table..? If so run a check to see if all the ID's from the parent table exist in the custom table..
Something like:
=================== CODE ===============
Select ContactId from Contact
Where ContactId not in(Select Contactid from C_Contact_Ext)
If you find any then use
Insert Into C_Contact_Ext(ContactId)
Select ContactId from Contact
Where ContactId not in(Select Contactid from C_Contact_Ext)
=========================================
Even though the controls are data bound to the custom table the ID doesn't exists so there is row row to update.. Just a shot..!
Rich |
|
|
|