also what about the contraint DF_CalendarEventEntry_IsBusy that is related to the IsBusy field? Should I delete that too?

decided to comment-out that CREATE TABLE and run the script and then it throws error at:

INSERT INTO CalendarEventEntry

([CalendarId]

,[CalendarEventId])

SELECT CalendarId, Id FROM CalendarEvent

Msg 207, Level 16, State 1, Line 42

Invalid column name 'CalendarId'.

</br>

</br>

I see the CalendarEvent has columns Id and OwnerCalendarId, but not CalendarId

event when I changed CalendarId to OwnerCalendarId in that last issue, it complained later on that a primary key already existed at
</br>
</br>

ALTER TABLE dbo.CalendarEventEntry ADD CONSTRAINT

PK_CalendarEventEntry PRIMARY KEY CLUSTERED

(

CalendarId,

CalendarEventId

) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

luckily the script uses transactions, so no damage was done from testing it (I hope)

I ended up renaming the old dbo.CalendarEventEntry to dbo._CalendarEventEntry and editing the script to write

INSERT INTO CalendarEventEntry

([CalendarId]

,[CalendarEventId])

SELECT OwnerCalendarId, Id FROM CalendarEvent

(it was saying SELECT CalendarId, Id there)
</br>
</br>and then it run fine (fingers crossed about the implications of that edit)

oops, I also had to remove
</br>

ALTER TABLE dbo.CalendarEvent

DROP COLUMN CalendarId

for the transaction to execute (didn't notice that the "8 row(s) affected" wasn't shown - it was showing a green tick and a row of error info [because of the catch block you have there, maybe should remove it since it can confuse the user])

Hi,

yes you should run 3321, 3378, 3381, 3471, 3507, 3540, 3715, 3765, 3824, 3842 & 4545 in this particular order. I noticed that you got an error related to CalendarEventEntry in 3321 so we will test this against the 4.5.3016.35 and get back to you shortly.

After all did you manage to upgrade to the latest version or you are still on the 3321 ?

Regards

the thing is that I was using db version, not monox version when looking at those folders

this can be very confusing since they use similar numbering pattern

now I did it using the monox version of my old site instead, hope this is the correct way

Hi Zoomicon,

Have you managed to upgrade it completely, or do you still have some issues?
If you are still encountering some issues, please send us detailed report.

Regards,
Darjan Bogdan

yes, I had to go back to the backup db I had taken before starting the process then starting again

some readme.txt should exist in the SQL scripts folder to tell the user what to do and note there that those are monox versions they should compare against, not monox database versions

also, it would be nice if there was some automated process (say PowerShell to run those scripts [asking you what your monox version was and then finding folders and files needed to run automatically and running them, notifying you as it proceeds through each step)