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!
|
|
Releasing Plugins
Posted: 06 Sep 06 7:04 AM
|
fiogf49gjkf0d I have done a development in SLX623 in the area of OpportunityProduct, where I have added a new table off OpportunityProduct, made changes to the Forms Add Opportunity Product and Products, and to the Script Insert Opportunity Common. I did this in a develoment database, and Bundled the changes.
In our Production DB I installed the Bundle, and released all the Plugins to everyone, and for our Network users it all works fine. But at least one Remote Syncing user gets a SQL error which I can't understand, but it looks like the new table may not be in his database.
Have I missed something in the deployment of this? Its the first time I have deployed one of my own changes so its quite possible.
Thanks.
|
|
|
|
Re: Releasing Plugins
Posted: 06 Sep 06 9:08 AM
|
fiogf49gjkf0d Originally posted by Stuart
Have I missed something in the deployment of this? Its the first time I have deployed one of my own changes so its quite possible.
|
|
No you did everythig right. Sounds like there is something wrong with that remote database or on the remote user's PC. Did you check the syncerrors.txt and application event log on the remote?
If I was you I would create the remote user another database and install it. |
|
|
|
Re: Releasing Plugins
Posted: 06 Sep 06 9:35 AM
|
fiogf49gjkf0d Originally posted by Frank Chaffin
If I was you I would create the remote user another database and install it. |
|
Thanks, that is what we are doing.
|
|
|
|
Re: Releasing Plugins
Posted: 07 Sep 06 6:05 AM
|
fiogf49gjkf0d But at least one Remote Syncing user gets a SQL error which I can't understand, but it looks like the new table may not be in his database.
What is the error message the remote user is getting?
It could very well be the table is missing from the remote database if you did not release it to remote users in DB manager. Find the customer table in the DB manager, right-click it and select Properties from the pop-up menu. Make sure
Sync this table out to remotes
and
Sync this table from remotes into the main database
are checked.
John G. |
|
|
|
Re: Releasing Plugins
Posted: 07 Sep 06 7:22 AM
|
fiogf49gjkf0d Originally posted by John Gundrum
What is the error message the remote user is getting? |
|
Failed to parse SQL at line 108, char 10 - this is when its trying to read my new table
Make sure
Sync this table out to remotes
and
Sync this table from remotes into the main database
are checked. |
|
They are
|
|
|
|
Re: Releasing Plugins
Posted: 07 Sep 06 10:35 AM
|
fiogf49gjkf0d Sounds like something is up with the SQL. What is the SQL statement?
John G. |
|
|
|
Re: Releasing Plugins
Posted: 08 Sep 06 8:00 AM
|
fiogf49gjkf0d I think Frank is right, its his database which has something wrong, because this works for all users execpt this one, so I can't see how the SQL can be wrong for just one user. |
|
|
|
Re: Releasing Plugins
Posted: 26 Sep 06 6:52 AM
|
fiogf49gjkf0d I have finally got to the bottom of this, so I thought I would post here what the problem was.
The SQL executing on the remote database was this:
Select [some columns]
From sysdba.OPPORTUNITY_PRODUCT op
Inner Join sysdba.PRODUCT p
On (op.PRODUCTID = p.PRODUCTID)
Left Outer Join sysdba.OAG_OPPORTUNITYPRODUCT oag
On (op.OPPPRODUCTID = oag.OPPPRODUCTID)
Where OPPORTUNITYID = 'O6UJ9A000GJE'
Order By op.SORT
And it was getting this error message:
Cannot resolve collation conflict for equal to operation.
Looking at the tables being joined, the problem was with this:
On (op.OPPPRODUCTID = oag.OPPPRODUCTID)
The Collation on the 1st column was SQL_Latin1_General_CP1_CI_AS
The Collation on the 2nd column was Database Default - Latin1_General_CI_AS
When I made them the same the error stopped.
I'm not sure if I did something wrong setting up the table in the first place,
or if SLX doesn't handle replicating Collation properly, but its fixed now 
|
|
|
|
Re: Releasing Plugins
Posted: 27 Sep 06 2:08 AM
|
fiogf49gjkf0d This is a known issue that isn't resolved (excuse the pun) in any release that I know of. Depending on the customisations you do - applying them to a production server sometimes has disastrous results. We have had the issue on many sites.
Tell me - does your production system have a full (enterprise) license or standard ?
Did you stop sync server when applying the changes in the bundle ?
Did you create a whole new table and, in the bundle, have the create table ?
Did you add any fields to other tables and, if so, did you use the create table or insert field option in bundler ?
It appears to be around this area that, sometimes, it goes wrong for remotes - but never the host.
|
|
|
|
Re: Releasing Plugins
Posted: 27 Sep 06 2:18 AM
|
fiogf49gjkf0d Originally posted by Mike Spragg
This is a known issue that isn't resolved (excuse the pun) in any release that I know of. Depending on the customisations you do - applying them to a production server sometimes has disastrous results. We have had the issue on many sites.
Tell me - does your production system have a full (enterprise) license or standard ?
|
|
I don't know, but will find out
| Did you stop sync server when applying the changes in the bundle ? |
|
No - should I have?
| Did you create a whole new table and, in the bundle, have the create table ? |
|
Yes I did both
| Did you add any fields to other tables and, if so, did you use the create table or insert field option in bundler ? |
|
No - just added a new table, and there were some changes to forms and scripts too
| It appears to be around this area that, sometimes, it goes wrong for remotes - but never the host. |
|
Thanks for looking at this.
|
|
|
|
Re: Releasing Plugins
Posted: 27 Sep 06 3:27 AM
|
fiogf49gjkf0d Originally posted by Stuart
I don't know, but will find out |
|
Our contract doesn't say, but on the basis that Enterprise is unlimited users and we need to buy individual licences, I think we must be standard.
|
|
|
|
Re: Releasing Plugins
Posted: 13 Aug 08 10:32 AM
|
hello.
i have the same problem.but when i control the collations are the same.... What's the solution? |
|
|
|
Re: Releasing Plugins
Posted: 14 Aug 08 4:25 AM
|
| In what way is it 'the same problem'? I don't understand. |
|
|
|
Re: Releasing Plugins
Posted: 14 Aug 08 4:36 AM
|
Remote users had the same error message (cannot resolve collation conflict..).
But i found the solutions! I have just regenerated remote databases and all run!
Sorry if i'm not very clear , i'm french and it's not easy to explain myself.
Thank you Stuart
Bien à Vous |
|
|
|
Re: Releasing Plugins
Posted: 18 Aug 08 7:20 PM
|
My client has just run into this issue - SLX 7.2.1 on SS2005.
Bundle added a single new field to a custom 1-> many table hanging off Opportunity.
The host db was unaffected, but the remotes have had the default collation changed on their databases.
As per this thread, I have advised them to try re-cutting a remote to see whether than resolves the issue.
For a client with 100s of remotes, this would clearly be a major pain. Were you able to resolve the problem without re-cutting the remotes? If so, how did you do it?
Thanks
Phil |
|
|
|
Re: Releasing Plugins
Posted: 01 Sep 08 5:20 AM
|
| We only have a handful of remotes, and we changed the Collation on the individual columns affected on the remotes using SQL Server Enterprise Manager. Against the SLX rules, I know, but it seemed to work, and less of a pain that recutting them. Still a pain nonetheless. |
|
|
|
Re: Releasing Plugins
Posted: 01 Sep 08 10:19 PM
|
Thanks Stuart
Just clarifying exactly what happened here ... It may help someone in the future.
So the problem that you had, specifically, was that you created some new columns in existing tables and then bundled the changes ...
When the changes sync'ed out to remotes, the collation order of just those columns was set to something different from database default? But the columns on the host db were created perfectly.
And then you were able to fix the problems by (effectively) issuing ALTER COLUMN ....... COLLATE commands for the affected columns.
Regards
Phil |
|
|
|
Re: Releasing Plugins
Posted: 02 Sep 08 2:18 AM
|
In fact it was a whole new table. All the char and varchar columns in the new table picked up the remote's database default collation (which is different to the host database's default; why is a good question, but the host is in the UK and the remotes are in the US).
Because the remote's schema is effectively a copy of the host DB's schema, all the char and varchar columns in the existing tables have the host DB's collation, so any compare of a column in the new table with an existing table failed.
I had to change the new table's columns which were being compared back to the host DB's collation to make it work.
Phew! That's hard to explain. 
|
|
|
|