Is it considered good practice to always use fully qualified names in Snowflake worksheets ?
Asking because I sometimes see things like this:
CREATE OR REPLACE STAGE db.schema.mystage
url = 'xxxxx'
DESC STAGE db.schema.mystage
ALTER STAGE mystage
SET ...
where they don't use the fully qualified name for the ALTER STAGE because they say the contect menu for the worksheet is already set to the correct database and schema.
For me this seems inconsistent and potentially prone to error.
So is it good practice to always use fully qualified names in Snowflake worksheets ?
Yes it’s good practice to utilize fully qualified name. Particularly useful as you open multiple worksheets and avoid changing dB or schema.
As #patrick_at_snowflake mentions, this really comes down to how the scripts are being used and how you are differentiating environments. In the case where you are using databases to differentiate dev, uat, prod, etc. then it is useful to not specify the database in all of your object references. In that case, you may want to qualify schema only, so that running a script in a different environment is as simple as USE DATABASE prod_db or USE DATABASE dev_db without having to update every qualified object name.
When I am editing/experimenting/testing in the worksheet I use fully qualified names, so I can share SQL with team members and have it "just work" for them, no matter what there worksheet is pointing at.
When we run our code in prod, we replaced the database/schema names with tokens that are replaced depending on the deployment target. The nice thing about this is when you look at execution history you get fully qualified names, so can re-run queries without a lot of fiddling.
But I also would not use full names if I was writing a bug report/repro, as it db/schema is not needed, and a working example should have all the related data, imo.
I think it is always good practice to have fully qualified object names in your script, not just in the worksheet, but in general, including your UDFs and SPs.
This can help to avoid potential errors if you forget to switch between schemas or databases and data get updated into the wrong target, or reading from the wrong source.
It can help to save lots of your debugging time down the track.
Related
We're using SqlPackage to generate scripts via the Script action. Does anyone know a way to get it to exclude indexes? Can't seem to find a way.
The SqlPackage reference gives several /p: properties to do with excluding a whole raft of other object types, which we are using to good effect, but not indexes. Indexes we can only tweak, not exclude, it seems. We're using SQL 2017 but the same goes for SQL 2019.
Has anyone found a way to completely exclude indexes from the script, so that they are just left as they are on the target db, the same as can be done for all the other types of SQL object?
/p: ExcludeObjectTypes=(STRING) A semicolon-delimited list of object types that should be ignored during deployment.
Valid object type names are Aggregates, ApplicationRoles, Assemblies, AsymmetricKeys, BrokerPriorities, Certificates, ColumnEncryptionKeys, ColumnMasterKeys, Contracts, DatabaseRoles, DatabaseTriggers, Defaults, ExtendedProperties, ExternalDataSources, ExternalFileFormats, ExternalTables, Filegroups, FileTables, FullTextCatalogs, FullTextStoplists, MessageTypes, PartitionFunctions, PartitionSchemes, Permissions, Queues, RemoteServiceBindings, RoleMembership, Rules, ScalarValuedFunctions, SearchPropertyLists, SecurityPolicies, Sequences, Services, Signatures, StoredProcedures, SymmetricKeys, Synonyms, Tables, TableValuedFunctions, UserDefinedDataTypes, UserDefinedTableTypes, ClrUserDefinedTypes, Users, Views, XmlSchemaCollections, Audits, Credentials, CryptographicProviders, DatabaseAuditSpecifications, DatabaseScopedCredentials, Endpoints, ErrorMessages, EventNotifications, EventSessions, LinkedServerLogins, LinkedServers, Logins, Routes, ServerAuditSpecifications, ServerRoleMembership, ServerRoles, ServerTriggers.
Please note, we know about /p: DropIndexesNotInSource=True/False and /p: IgnoreIndexOptions=True/False but these are not sufficient.
I believe you need to use a publish.xml file. See this answer for the rough idea. The question it answers has a sample file. If you set up to not include indexes via the GUI then the file should contain something like <ExcludeIndexes>True</ExcludeIndexes>.
I have a scenario where Java developer has made the change to the variable which used to transfer the data from column - col of table - tbl.
Now, I have to change the column varchar(15) to varchar(10). But, before making this change - have to handle the existing data and the constraints/dependencies on same column.
What should be the best sequence of doing so?
I am thinking to check the constraints first, then trim the existing data and then alter the table.
Please suggest how to handle constrains/dependencies and before handling it, how to check such dependencies.
Schema-evolution (the DDL changes that happen over time to tables and columns in a database, while preserving existing data and functionality) is a well understood topic with several solutions, some of which are RDBMS independent, others are built-in to the RDBMS solution.
A key requirement for production environments is to need both a forward-change and a backout, which can be run unattended.
Many open source advocates use Liquibase which also has a commercial variant.
Db2 for Linux/Unix/Windows also offers a built-in stored-procedure SYSPROC.ALTOBJ which helps to automate various schema-evolution alterations, including decreasing the size of a column. You would need to study its documentation carefully and test it fully on non-production environments until you are satisfied. Read about it here
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.rtn.doc/doc/r0011934.html
You can grow-your-own script of course, in whatever language you prefer, including SQL, but remember you should also build and test a back-out script.
I just came across this when looking into someone else code.
Say there is this schema called Books that has a table call Genres...whenever this schema and table is being used on a script, such as batch/perl it was originally Books..Genres
question is, should it stay like this or changed to Books.Genres? and what is the difference?
First of all, I rarely work outside my default schema and thus rarely ever list the schema name in my SQL statements. Having said that, there are rare occasions when I do need to access more than one schema and only a single dot is used to separate the schema name from the table name. I checked both DB2 and Oracle: neither even allow a double dot. So, unless they are manipulating the SQL in some manner (e.g. maybe the code is processed in a template), SQL statements with a double dot should not work.
MySQL doesn't allow a double dot as separator either; so unless they're preprocessing the SQL in some way as kjpires suggested, this is likely an error. Does the code work?
I've got a large amount of access databases that need to have the same table design changes (and a few new tables created) in each of them. Is there any way to take my most recent (properly designed) database, export the design properties, and import them to each of the other databases overwriting changes and creating any new fields, tables, etc. as needed?
My research has only led me to the Database documenter which seems to only be helpful in cases where I'd manually update the properties. I also know I could potentially copy each table over manually specifying 'Structure Only' for each case but that'd be a rather daunting task and I'm unsure what exactly would be copied using this method.
Let me see if I have the outline...
Open Proper.mdb
For each OtherMDB in Folder1
Open OtherMDB
for each ProperTable in Proper.mdb
If ProperTable is absent from OtherMDB
Add ProperTable to OtherMDB
Else
For each Field in ProperTable.Fields
If ProperField is absent from OtherTable.Fields
Add Field to OtherTable
Elseif ' is this a possibility?? wanting to change field type?
ProperField.Type <> OtherTable.Field("xx").Type Then
Change Field.Type
endif
Next Field
Endif
Next Table
Close OtherMDB
Next MDB
I found a utility called DBWeigher which is able to analyze and compare two access databases and automatically generate the necessary VBcode to update the changes between the two. From here I quickly ran through the changes manually and was able to see firsthand what changes would be made prior to running them through the DBConsole.
For anyone trying to update older access databases (especially when they're at different stages and could have some variances), I can't suggest checking this lightweight utility out.
I have a very simple database in access, but for each record i need to attach a scanned in document (probably pdf). What is the best way to do this, the database should not just link to a file on the pc, but should copy and keep the file with it, meaning if the original file goes missing the database is moved or copied, the file should still be accessable from within the Database. Is This possible? and what is the easiest way of doing it? If is should i can write a macro, i just dont know where to start. and also when i display a report of the table, i would like to just see thumbnails of the documents.
Thank you.
As the other answerers have noted, storing file data inside a database table can be a questionable practice. That said, I wouldn't personally rule it out, though if you are going to take that option, I'd strongly suggest splitting out the file data into its own table in its own backend file. For example:
Create a new database file called Scanned files.mdb (or Scanned files.accdb).
Add a single table called Scans with fields such as FileID (AutoNumber, primary key), MainTableID (matches whatever is the primary key of the main table in the main database file), FileName (Text), FileExt (Text) and FileData ('OLE object', really just a BLOB - don't actually use OLE Objects because they will bloat the database horribly).
Back in the frontend, add a reference to Scans as a linked table.
Use a bit of VBA to upload and extract files from the Scans table (if you're interested in the mechanics of this, post a separate question).
Use the VBA Shell routine (if you must) or ShellExecute from the Windows API (= the better option IMO) to open extracted data.
If you are using the newer ACCDB format, then you have the 'attachment' field type available as smk081 suggests. This basically does most of the above steps for you, however doing things 'by hand' gives you greater flexibilty - for example, it allows giving each file a 'DateScanned' or 'DateEffective' field.
That said, your requirement for thumbnails will require explicit coding whatever option you take. It might be possible to leverage the Windows file previewing API, though I'd be certain thumbnails are a definite requirement before investigating this - Access VBA is powerful enough to encourage attempts at complex solutions, but frequently not clean and modern enough to allow fulfilling them in a particularly maintainable fashion.
There is an Attachment type under Data Type when you go into Design View of your table. You can add an attachment field here. When you go into the Datasheet view of the table you can select this field for a particular row and a window will open for you to specify the attachment. This will cause your database to quickly grow in size if you add a lot of large attachments.
You can use an OLE field in a table, but I would really suggest you not use this approach. The database is going to be HUGE in no time, and you're going to regret it.
Instead, you should consider adding a field that stores the path to the file, and keep the files in one folder on your network. Then you can use a SHELL() command to open the file. What's the difference between restoring an Access database and restoring PDF files if something goes wrong? This will keep your database at a manageable size and reduce the possibility of corruption.