In Snowflake, table views are appearing read-only. We are unable to perform basic excel like actions i.e. add new row / columns in a table OR sort etc. Is it a feature or we are missing out something?
Microsoft PowerApps doesn’t have Snowflake as their available DATA CONNECTORS. May I know the timeframe in which it will be available?
Views are, by definition, read-only (they are basically just a saved SELECT statement). If you want to change the data/columns that they display you need to change the tables that the View references and/or change the View definition.
No idea when PowerApps will have a Snowflake connector. You would need to ask Microsoft and unless it was imminent (or on a published roadmap) I doubt they would tell you
Related
Snowflake database storage includes (maybe there are some others)
tables
time travel
fail safe
clones
files staged
I am trying to find a way to calculate tables + time-travel + fail-safe with and without clones not using TABLE_STORAGE_METRICS.
Currently looking at ACCOUNT_USAGE.database_storage_usage_history, but I am not sure what is included in AVERAGE_DATABASE_BYTES.
How do I find the correct values for current database?
Edit:
I am not an account admin
Would like to use query instead of UI
Edit 2: Result from SELECT * FROM INFORMATION_SCHEMA.TABLE_STORAGE_METRICS;
With no IMPORTED privilege or permission to view SNOWFLAKE database.
The documentation is a great source of information on this:
https://docs.snowflake.com/en/sql-reference/account-usage/database_storage_usage_history.html#database-storage-usage-history-view
Number of bytes of database storage used, including data in Time
Travel.
Per your list, this would include tables, clones (which are tables on their own), and Time Travel.
For stages, you'd need to use the STAGE_STORAGE_USAGE_HISTORY view.
Is there a reason you don't want to use the TABLE_STORAGE_METRICS? Just curious.
If you are an accout admin, you should be able to see this on your snowflake console
I looked around for this task I have on my hands but did not find anything helpful. I am primarily a Java person with sound knowledge of database from software development point of view. I do have some knowledge of DBA functions with what can and cannot be done but not able to come up with a good solution.
The task I have is to compare the databases created in SQL Server and Oracle by our application installer.
I think I have been able to come up with some queries (of course, by searching online) in SQL Server that will give me things like number of tables in a schema, each table's columns with data types and indexes, different types of constraints, triggers, etc. (with their count) created for each of those tables. I can provide those SQLs if somebody is interested.
However, Oracle seem to be more tricky. I would appreciate if somebody can help or maybe point me in the right direction.
I am trying to find out somethings like following:
Number of tables created
Number of indexes, constraints (with their types), triggers for each of those tables
Number of stored procedures/functions created
Number of views created
Any help will be greatly appreciated.
Thank you.
First off, if you are already comfortable writing Java code, I'm not sure that I would be writing a bunch of SQL to do this comparison. JDBC already has a DatabaseMetaData class that has methods like getTables to get all the tables. That would give you one API to work with and let you leverage the fact that the folks that wrote the JDBC drivers already wrote all the code to query the data dictionary tables in whatever database you are using. This will also let you focus on differences in how the objects your installer creates will be perceived by the application.
If you are going to write specific SQL, the Oracle data dictionary tables are pretty easy to work with. The ones you'll care about are going to follow the pattern [user|all|dba]_<<type of thing>>. The [user|all|dba] prefix indicates whether you are looking for objects that you own (user), objects that you have access to (all), or all objects in the database (dba). Normal users often don't have access to the dba views because that is a potential security issue-- generally you don't want people to know that an object exists if they don't have access to it. In my examples, I'll use the all versions of the objects but you can change all to user or dba depending on what you're after.
all_tables will show you information about all the tables you have access to. You probably want to add a filter on owner for the schema(s) that your installer touches since you may have access to tables that are not part of your application.
all_indexes, all_constraints, and all_triggers will show you information about indexes, constraints, and triggers. Again, you may want to add a predicate on owner to limit yourself to the schema(s) that you care about.
all_procedures will show you information about procedures and functions both stand-alone and in packages.
all_views will show you information about all views.
If you are really just interested in counts, you may be able to simply go to all_objects and do a count grouping by object_type. I'm guessing that you'll want to see attributes of the various objects so you'll want to go to the various object-specific views.
We would like to give some of our customers the option to read data from our central database. The data is live and new records are being added every few seconds. Our database is MySQL running on Amazon RDS.
I was wondering what is the common practice for doing so.
One option would be to give them select right from specific tables, in that case they would be able to access other customers' data as well.
I have tried searching for database, interface, and API key words and some other key words, but I couldn't find a good answer.
Thanks!
Use REST for exposing specific tables to do CRUD operations. You can control the access on it too.
My database is an Access Data Project, tied to a SQL Server 2005 backend. I'm trying to bind a form to a view that uses an INSTEAD OF trigger. Access thinks the view isn't updatable, so it's making the form read-only; apparently it doesn't take the trigger into account.
I suspect the problem is that SQL Server's metadata says the view isn't updateable. Querying INFORMATION_SCHEMA.VIEWS, for example, shows IS_UPDATABLE = NO. Despite that, I definitely can update the view by using UPDATE statements or using the SSMS GUI.
Is anyone aware of a method I can use to convince Access that this view really is updatable? I know there are other ways I could get read-write access to this form, but I was planning to use this view to limit certain users' access to a very specific subset of data, and it would make things a lot easier if I could encapsulate all of that data within this one view.
Access requires a PK on the linked table in order for it to be updateable - I think this is so the JET (or whatever the new one is) engine can uniquely identify the row to change.
This means you need to convert this view into an indexed view, which is a whole other can of potentially very complicated worms.
I'm making a VB.NET application with an SQL Server 2005 in the background. Naturally the user can not edit the database directly but will use a number of UI features to be able to add and modify the data.
However, there are a few tables that should be easily accessible from the admin interface such as specific information about a vendor. What's the easiest way to let the user edit this data freely? One way would be to use a DataGridView but this could appear complicated to the user, plus I'm not sure exactly when to save the edited data back to the database.
The best way that I can think of is to create custom dialog boxes for adding, deleting and changing the information, but this seems like too much work for such a small feature.
You are either going to have to give them the data in a table format (like with the DataGridView) or you are going to need to build something that lets them edit individual records (like custom forms). It seems like a lot of work (and it can be) but there are some ways to cut down on the amount of work.
Check out how to use databinding in VB.NET. There's a tutorial here, another one here and many others out there. You can use databinding for both a table view or for individual records. Using a DataGridView isn't too complicated for a user as long as you build in the necessary support in code - make sure the row is saved if it has been changed and they move to another row (or prompt them), disable editing on columns that they shouldn't be able to change, validate the data before writing it back to the database, etc.
There are also code-generation tools like CodeSmith that can create a data access layer between the GUI and the database. Some of the templates you can get will even generate the actual forms for you.
The only other option I can think of is to give them direct access to the database through tools like SQL Server Management Studio and setting up logins that only have permission to specific tables/views but I would STRONGLY recommend against that.