SQL 4.3 upgrade script doubled tables

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
3 years ago
Yep, that's a bug in the upgrade script. It should not be hard-coding [dbo] as it may not be installed under that schema. Well spotted sir!



tomsen wrote:
Pls. have a look at the upgrade sql script 4.2 => 4.3:

--new column
IF EXISTS (SELECT 1 FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[ShippingByWeightByTotalRecord]') and OBJECTPROPERTY(object_id, N'IsUserTable') = 1)
and NOT EXISTS (SELECT 1 FROM sys.columns WHERE object_id = object_id('[ShippingByWeightByTotalRecord]') AND NAME = 'TransitDays')
BEGIN
  ALTER TABLE [ShippingByWeightByTotalRecord]
  ADD TransitDays int NULL
END
GO

I added the transitdays with SSMS to keep the Shipping Plugin "working".
Jon Quick
0
3 years ago
Using third party plugins from nop-templates.

Cannot find any entries besides dataSettings.json.

Hmm.
0
3 years ago
Thanks a lot for reporting.

We've just fixed and re-uploaded the upgrade script
Interested in the dedicated Premium support services provided by core developers? Please visit https://www.nopcommerce.com/nopcommerce-premium-support-services

Regards,
Andrei Mazulnitsyn
nopCommerce team
0
3 years ago
Even those places that we fixed could not lead to duplication of tables. It is more likely that the upgrade script was executed on behalf of the user whose default scheme  is DBO, and not on behalf of the user through which nopCommerce work with database
Interested in the dedicated Premium support services provided by core developers? Please visit https://www.nopcommerce.com/nopcommerce-premium-support-services

Regards,
Sergey Koshelev
0
3 years ago
What I didn't understand was the original poster observation that 'I delete dbo. objects but they are recreated automatically'  (he does not say he re-ran the script)

my thinking was...

1) script was run successfully again schema sample.* (apart from one small problem in script with hardcoded dbo. - now fixed)
2) NopCommerce is run with a sql user defined in datasettings.json with a default schema dbo.  (the sa account for example). Then the fluent migrator has created the dbo.* objects alongside sample.*
3) datasettings.json was changed to alternative user than has sample. as the default schema. Everything works against .sample ok.

Strange stuff :D

Sergei-k wrote:
Even those places that we fixed could not lead to duplication of tables. It is more likely that the upgrade script was executed on behalf of the user whose default scheme  is DBO, and not on behalf of the user through which nopCommerce work with database
Jon Quick
0
3 years ago
Thank you so much for your efforts.

Should i retry deleting the [dbo].table tables?

Should i rename the plugin [dbo].plugintable to [sample].plugintable before retry deleting the [dbo].table tables?
0
3 years ago
If your certain the app is now looking at sample. schema, I would take a full SQL backup, and then maybe delete one of the dbo. tables as a test (which is easy to recreate manually), such as dbo.TopicTemplate  - then see if it is recreated automatically.

I'm not sure what [dbo].plugintable is? maybe from an older version of nopcommerce? Or a table created by a 3rd party plugin?

Just tread carefully, take backups along the way.
Jon

tomsen wrote:
Thank you so much for your efforts.

Should i retry deleting the [dbo].table tables?

Should i rename the plugin [dbo].plugintable to [sample].plugintable before retry deleting the [dbo].table tables?
Jon Quick
0
3 years ago
ok, fine.

[dbo].plugintable stands for the tables created from plugins like [dbo].SS_Conf and alike.
0
3 years ago
Understood, sure.

tomsen wrote:


[dbo].plugintable stands for the tables created from plugins like [dbo].SS_Conf and alike.
Jon Quick
0
3 years ago
little behaviour description:

The (wrong) "[dbo].MigrationVersionInfo" is restored if something is clicked in nopcommerce admin area.
0
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.