the big gotcha is that any on-open routines will also run. If you don not want that, check with get(applicationversion) to branch around code you do not want executed.
Write your script so it can run locally or server side - add an auto switch so it runs server side on server and locally when not on server. Add a manual switch to toggle this setting when debugging.
I have found this method helps debug complex server side stuff as well as dealing gracefully with when the file is on you local machine.
Add an events table - your own log - to easily capture what is happening during a server side session and track errors.
# without logging an error:401 If [ Case ( not PatternCount ( Get ( ApplicationVersion ) ; "Server" ) ; true ; // on Server ExecuteSQL ( " SELECT COUNT ( pk_id ) FROM tableName WHERE ..." ; "" ; "" ) ) ] Perform Find  Set Variable [$error; Value:Get ( LastError )] If [not $error] ... End If End If -------------------------------------------------- # without logging an error:101 Set Variable [$foundCount; Value:Get ( FoundCount )] Set Variable [$i; Value:0] Loop Exit Loop If [$i ≥ $foundCount] Set Variable [$i; Value:$i + 1] Go to Record/Request/Page [No dialog; $i] End Loop
Like all bits of true genius in hindsight this is obvious! I guess I am retro fitting some loop scripts today :-). It seems preferable to actually have an explicit loop end statement if only for readable code.
I setup error capture at each break point and use smtp email to email me error message. I did a blog post about this a couple of years ago at NYFMP.org
It goes beyond debugging. If you have a mission critical server side script ,getting an email, with a specific error, is a nice added benefit.