It depends on how you define "sql script file".
For example, Oracle's dialect of sql script file has several extensions that are handled by the script interpreter, not by database (such as spooling, defining variables and so on). Oracle furthermore has several command separators (the forward slash and a semicolon) that must be handled correctly, and even has commands that allow these separators to be overridden. In short, to be able to run any sql script file that can be processed by Oracle's Sql*plus, you'd have to fully replicate all these capabilities. That would be a lot of work.
Other databases and/or sql clients can have their own extensions.
There are generally two ways to go:
1) Define your own "sql script file": make it clear which commands are supported and which aren't. Implement your application to conform to the specification. Then you're able to tell yourself which files will work and which won't. (Of course you can use an existing specification, for example Oracle's I've already mentioned, but it will probably be a lot of work.)
2) Let the hard work of parsing and executing the script be done by a call to the SQL client, in a way similar to running Windows' BAT file. Most SQL clients should support passing the connection information and a name of the SQL file to execute on the command line.
Then there is a third option: let your users use the SQL client directly (mentioning just for completeness
).