Tag Info

New answers tagged

0

Courtesy Materialized views are disk based and are updated periodically based upon the query definition. Views are virtual only and run the query definition each time they are accessed. Materialized Views advantage over View is, it's depends on the data. If data is too large view take much time to execute because it does not store data, during the ...


3

As you have multiple rows inside the JSON column, you need a function that returns a set. This can be done using the json_to_recordset() function: select j.* from json_test, json_to_recordset(json_data) as j(name text, country text, hobby text, address text, sex text); Because this is an anonymous record type, you must explicitly define each column. ...


6

When a view is created it is bound to the metadata it needs in order to execute. Note: https://msdn.microsoft.com/en-us/library/ms187821.aspx That says that sp_refreshview: "Updates the metadata for the specified non-schema-bound view. Persistent metadata for a view can become outdated because of changes to the underlying objects upon which the view ...


2

That's a typical case of case misuse. When creating the view, notice that "objectifsBoutique" is written with a uppercase B plus double quotes. This implies that any future reference to this object must include the uppercase B. Yet in the error message « objectifsboutique » relation is not found it's a lowercase b so that name does not refer to the view, ...


1

Views are a good way to accomplish what you want to do. If your views take advantage of existing indexes or are 1:1 against the underlying tables, then queries against them will use the indexes. Since you're expecting periodic updates, you'll want to script the view creation, and in that same deployment script you can always add indexes if you need more. ...


2

Do you have a calendar table ? I am building a kind of calendar table with object cteSeries. Then adjust the Initial_Date and Final_Date to hold BOM (beginning of Month YYYY-MM-01) in cteSample , fields: Initial_Date_M,Final_Date_M DECLARE @tSample TABLE ( Product VARCHAR(10) ,Price DECIMAL(18,2) ,Initial_Date DATE ,Final_Date DATE) INSERT ...


1

I am pretty sure the reason is that customerid in the view is the result of: COALESCE(b.customerid, s.customerid::bigint) After LEFT JOIN, cast & COALESCE, the predicate cannot be pushed down, so both tables have to be read in full, before the filter customerid = 520001215 can be applied. The fact that customerid can be NULL in both tables is not ...


-3

Do you have clustered and nonclustered indexes? Try clustered index on receipt number and date. And non clustered index on receipt number, receipt position, date, and price



Top 50 recent answers are included