How do I remove a summation property for a Power BI SQL table? I have a Customer Transaction Table. For some reason PowerBI is trying to Measure Sum the CustomerTransactionId primary key row. I do not want this added. Please see picture below.
I just want to display all rows in a table.
CREATE TABLE [dbo].[CustomerTransaction]
(
[Customertransactionid] [int] IDENTITY(1,1) primary key NOT NULL,
[Customerid] [int] NULL,
[Quantitybought] [int] NULL,
)
msdn
This is actually done in PowerBI under the modeling ribbon/tab.
When you click on a field (on the right where they are all listed under Fields is fine), the modeling ribbon changes to reflect all settings for that particular field.
Under Default Summarization select 'Do not summarize'.
PowerBI sets Default Summarizations regardless of the data source.
Related
I have an Access database that uses SQL Server as its backend. One table is the data for a subform which is loaded into a parent form and displayed in the parent forma as a datasheet. The datasheet is intended to have rows added to it by users.
The subform backend table is defined in SQL Server with a primary key [ID]. The primary key is linked to the Master ID of the current record displayed in the parent form. The subform is then filtered by the relationship between the subform table primary key and the parent form master ID. Nothing unusual here.
The problem that when the parent form is first opened in Access the subform is cannot have records added. It is not until the linked table manager is opened and the backend table is RELINKED can the user add records to the subform. Oddly enough, when relinking the table I am always prompted for the primary key of the table even though it is defined in SQL Server.
The subform has the following settings
Data Entry: Yes
Allow Additions: Yes
Allow Deletions: Yes
Allow Edits: Yes
Allow Filters: Yes
Record Locks: No Locks
Here is the CREATE TABLE for the backend table:
CREATE TABLE [dbo].[ProjectHealth](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Project Health] [nvarchar](2000) NULL,
[Timestamp] [datetime] NULL,
[ProjectID] [int] NULL,
[Entered By] [nvarchar](255) NULL
) ON [PRIMARY]
GO
Again, the RELINK solves the problem. But a VBA TableDef.Refreshlink call does not do the trick. Even if I reset the primary key from VBA.
My suspicion is that I have modified some value in the subform settings that have caused this problem which started happening after a few days of normal behavior. Thanks in advance for any suggestions you can provide.
I have 2 tables, one containing a bunch of polygons like this
CREATE TABLE [dbo].[GeoPolygons](
[OID] [int] IDENTITY(1,1) NOT NULL,
[Version] [int] NULL,
[entity_id] [varchar](200) NULL,
[Geometry] [geometry] NULL
)
and one containing a bunch of nodes (places) like this
CREATE TABLE [dbo].[GeoPoints](
[point_id] [int] NOT NULL,
[point_name] [varchar](40) NULL,
[latitude] [decimal](8, 6) NULL,
[longitude] [decimal](9, 6) NULL,
[point_geometry] [geography] NULL
)
These tables came from disparate sources, so one has a geography field type and the other has a geometry field type.
What I want to do - which is very possible within my GIS, but I want to do it in T-SQL for a variety of reasons - is find out which nodes are inside which polygons.
Is the first step to match the geo-field types? geometry-to-geometry or geography-to-geography?
Or can that be done on the fly?
My ideal output would be a 3 field table
CREATE TABLE [dbo].[Points2Polygons](
[match_id] [int] IDENTITY(1,1) NOT NULL,
[entity_id] [varchar](200) NOT NULL,
[point_id] [int] NOT NULL
)
and be able to update that on the fly (or perhaps daily) when new records are added to each table.
I found this post but it seems to deal with a single point and a single polygon, as well as WKT definitions. I don't have WKT, and I have thousands of polys and thousands of points. I want to do it at a larger scale.
How do I do it in a T-SQL query?
Server is running SQL-Server Web 64-bit V15.0.4138.2 on Server 2019 Datacenter.
TIA
From the comments above, here's a proposal to convert the Geometry column in your GeoPolygons table. As with anything like this where you have data one way and you want it to look a different way on an ongoing basis, the high level steps are:
Start writing the data in both formats
Convert the old format into the new format
Convert all read paths to the new format
Drop the old format
I'll be focusing on "Convert the old format into the new format". Create a new column in your table (I'll call it Polygon).
alter table [dbo].[GeoPolygons] add
Polygon geography null;
Note that this is a prerequisite for the "Start writing the data in both formats" phase and so should already be done by the time you're ready to convert data.
The most straightforward method to do that looks like this:
update [dbo].[GeoPolygons]
set [Polygon] = geography::STGeomFromText(
[Geometry].STAsText(),
[Geometry].STSrid
)
where [Geometry] is not null
and [Polygon] is null;
I'm making the assumption that the SRID on your Geometry column is set properly. If not, you'll have to find the SRID that is appropriate given the WKT that was used to create t
I have a table ApplicationRegion in a one-to-many relationship to Translation.
I want to set FK's from Translation.appname/isocode to ApplicationRegion.appname/isocode
But that did not work as you can see from the screenshot.
When the FK configure window opens 3 columns are shown on the left/right side
appname
isocode
resourcekey
Then I chose as parent table ApplicationRegion and removed the resource key column from the FK setting.
And clicked OK but then I got the error you see on the screenshot.
Finally I made it work with that workaround and I would like to know why I had to use this workaround?
Remove PK from Translation.ResourceKey column
Open FK configure window
Only 2 columns appear now as foreign keys
I click OK
Now I add the PK again to Translation.ResouceKey column
I added test data to all 3 tables and everything is fine.
WHY this workaround?
UPDATE
HAHA...
I think you must have hit a weird glitch in SSMS. I was able to create your schema using SSMS 2014 without any errors. It did pre-fill the three composite primary key columns when adding the new FK. I was careful to make sure they were all blanked out before I started to add the two columns in the FK. Maybe SSMS thought one of the blank rows still had data in it.
Edit: Just had one more thought, SSMS is know for caching any changes that are made when editing a table. For example, if you go to modify two tables and have both edit windows open. Then you change the PK in one window and then try to reference it in the second window, it will error because it has cached what the schema was for the first table when the window was first opened.
Here is my generated DDL:
CREATE TABLE [dbo].[AppRegion](
[appname] [nvarchar](50) NOT NULL,
[isocode] [char](5) NOT NULL,
CONSTRAINT [PK_AppRegion] PRIMARY KEY CLUSTERED
(
[appname] ASC,
[isocode] ASC
)
) ON [PRIMARY]
CREATE TABLE [dbo].[Translation](
[ResourceKey] [nvarchar](128) NOT NULL,
[appname] [nvarchar](50) NOT NULL,
[isocode] [char](5) NOT NULL,
[text] [nvarchar](400) NULL,
CONSTRAINT [PK_Translation] PRIMARY KEY CLUSTERED
(
[ResourceKey] ASC,
[appname] ASC,
[isocode] ASC
)
) ON [PRIMARY]
ALTER TABLE [dbo].[Translation] ADD CONSTRAINT [FK_Translation_AppRegion] FOREIGN KEY([appname], [isocode])
REFERENCES [dbo].[AppRegion] ([appname], [isocode])
I am using a SQL Server 2008 database.
I have two databases namely db1 and db2. In both there is a table tblcountry. I create this on 1st database. Then how can I script with its data for create on 2nd database?
I use the code below
CREATE TABLE [dbo].[tblCountry]
(
[record_Id] [int] IDENTITY(1,1) NOT NULL,
[country] [nvarchar](150) NULL,
[nationality] [nvarchar](150) NULL,
[lsdMdfdOn] [datetime] NULL,
[lstMdfdBy] [nvarchar](350) NULL,
[isDeleted] [bit] NULL,
[isEnabled] [bit] NULL,
)
Then what code will I use for the getting include the data?
No, you cannot view the data if you are using the create query.
If you want to see the data of the table on second database then you can use this query on your second database db2
select * from [db1].[dbo].[tblCountry]
But you can not view the data and create query at the same time.
Although it may seem very wierd solution but I guess what you can do is you can copy the create query on the query analyzer window and beneath that write the select query and execute it. (But I guess this is how most of the programmers do that)
If you are on the same server or have a linked server:
CREATE TABLE tblCountry
SET IDENTITY_INSERT tblCountry ON
INSERT INTO [database2].tblCountry
SELECT * FROM [database1].tblCountry
SET IDENTITY_INSERT tblCountry OFF
The most Easy way for this problem is for you to
Right Click on the Database on the Object Explorer
click Generate Scripts
on the introduction click Next
Select radio button on Script entire database and all database
objects or you can just select specific tables or stored
procedures by selecting the other radio button
On the Set Scripting Options click on Advanced Select the things you
want to script
Then on the Query just change the database name after the query USE
db2
Right click on database and click on tasks and export data
you can use export data option in sql server...it will give you data with table script
I have a database that the client needs to update. They like to use access. Some tables randomly become read-only for them. Any ideas why?
They are using Access 2007 and MS SQL 2005.
SQL Table:
CREATE TABLE [dbo].[Users](
[SyncGroup] [varchar](20) NULL,
[UserID] [varchar](20) NOT NULL,
[Password] [varchar](20) NOT NULL,
[Restriction] [text] NULL DEFAULT (' '),
[SiteCode] [varchar](20) NULL,
[Group] [varchar](20) NULL,
[EmpId] [varchar](20) NULL,
[TimeZoneOffset] [int] NULL,
[UseDaylightSavings] [bit] NULL,
PRIMARY KEY ([UserID]) )
Access really likes having a TimeStamp aka RowVersion field on every table. I don't know if this will fix your problem though.
"On servers that support them (such as Microsoft SQL Server), timestamp fields make updating records more efficient. Timestamp fields are maintained by the server and are updated every time the record is updated. If you have a timestamp field, Microsoft Access needs to check only the unique index and the timestamp field to see whether the record has changed since it was last retrieved from the server. Otherwise, Microsoft Access must check all the fields in the record. If you add a timestamp field to an attached table, re-attach the table in order to inform Microsoft Access of the new field."
http://technet.microsoft.com/en-us/library/cc917601.aspx
are users accessing the database while you're trying to do stuff iwth sql? if so, then you will get an error message stating that the database is in use and is read only. no one can be in the database when you are doing things with it though sql.
Sounds like a permissions problem. Are you keeping careful track of who is altering the schema? You may have users who aren't permitted to use changes made by certain other users.