Hi Matthias,
Ok - this is the case here. ili2pg creates bigint pkeys. That explains
why I see the "unrelated" internal pkeys from QGIS instead.
It would be really nice if we had an option to create normal "integer"
pkeys with ili2pg instead of bigint. Other GIS (like Geomedia) had
issues
Hi
It depends on the implementation in the data provider (and normally on the
data type for the primary key).
In the postgres case, (up to) 32 bit integer primary keys are normally used
as fid.
With others like 64 bit integer, string or compound foreign keys it's not
possible to stick to this
Ok - that explains it.
It is quite confusing that QGIS uses a different internal ID than the
primary key column of the database. Is there a technical reason for this
behaviour?
Andreas
On Thu, 8 Jul 2021 at 11:43, Alexandre Neto wrote:
> As far as I remember @atlas_featureid has always
As far as I remember @atlas_featureid has always returned the same as the
$id in the attributes table, which is kind of the internal row number.
Alex
A quinta, 8/07/2021, 10:35, Andreas Neumann escreveu:
> HI Jürgen,
>
> Yes - I provided the primary key column
>
> Here is my data source
HI Jürgen,
Yes - I provided the primary key column
Here is my data source string:
service='edit' authcfg=sogis00 key='t_id' srid=2056 type=Polygon
checkPrimaryKeyUnicity='1'
table="alw_strukturverbesserungen"."projekt_aggregiert_v"
(geometrie_convex_hull) sql=geometrie_bbox IS NOT NULL
Hi Andreas,
On Thu, 08. Jul 2021 at 10:30:08 +0200, Andreas Neumann wrote:
> attribute(@atlas_feature,'pkey_name'), but it is a little more complicated
> than @atlas_featureid - and I'm pretty sure that @atlas_featureid was using
> the pkey column in th past?
>
> My data source for the atlas
Hi,
I haven't worked on an Atlas for a while, now again in QGIS 3.16.
I was surprised to see that @atlas_featureid is not equal to the primary
key of the atlas coverage layer.
Is this expected or a bug? I know, I can access the primary key through
attribute(@atlas_feature,'pkey_name'), but
