|
nagir
|
Posted 2009-03-26 08:38:22
|
|
Group: Forum Members
Last Active: 2010-08-11 17:02:44
Posts: 338,
Visits: 890
|
Hi,
I have a lookup class (Country) that is defined like this:
Id: int (persistent)
OrderIndex: int (persistent)
Description: string (persistent)
the table looks like this:
create table Country (
[Id] int not null primary key clustered,
OrderIndex int not null default(0),
Description nvarchar(255)
)
NOTE THE Id attribute:
- it is accessible from ECO object
- it is changable at any time
- it maps to PK in a table
Now I need to write mapping for this. I try this:
<ClassDef Name="GeneralLookup" />
<ClassDef Name="Country" SuperClass="GeneralLookup">
<AliasDef Name="c" Table="Country">
<KeyImpl Name="EcoKey" IsAutoInc="False">
<KeyColumn Name="Id" />
</KeyImpl>
</AliasDef>
<KeyDef Name="EcoKey" Signature="System.Int32" IsId="True" KeyMapper="Attribute" />
<AttributeDef Name="Id" Alias="c" Columns="Id" />
<AttributeDef Name="Description" Alias="c" Columns="Description" />
<AttributeDef Name="OrderIndex" Alias="c" Columns="OrderIndex" />
<AttributeDef Name="TaxPercents" Alias="c" Columns="TaxPercents" />
</ClassDef>
But it fails with error:
Country.Id is mapped to the same column as the key "Id". Country.Id must have "SaveAction = Freeze" set in the model
ECO correctly determines the Id is a PK, but does not allow me to use it.
How can implement the described scenario?
Thanks,
Dmitriy.
My Blog: http://dnagir.blogspot.com
|
|
|
|
|
Peter Morris
|
Posted 2009-03-26 11:26:16
|
|
Group: Forum Members
Last Active: 2011-07-14 18:05:00
Posts: 290,
Visits: 2 617
|
Have you tried setting the SaveAction on ID to Freeze like the error message says?
====
Pete
|
|
|
|
|
nagir
|
Posted 2009-03-27 00:05:01
|
|
Group: Forum Members
Last Active: 2010-08-11 17:02:44
Posts: 338,
Visits: 890
|
Yes, of course. It does work with it, but I cannot change the PK after the object is saved.
It will be needed soon, for now I left "Freeze".
Is it really impossible to change PKs from ECO??
My Blog: http://dnagir.blogspot.com
|
|
|
|
|
Jonas Hogstrom
|
Posted 2009-03-29 16:30:20
|
|
Group: Administrators
Last Active: 2010-11-30 13:17:13
Posts: 1 230,
Visits: 1 382
|
Yes, you can't change the primary key of an ECO object. Normally, we use syntetic keys (ECO_ID) to make it easier for you to keep your hands of the object identity. When you map an attribute as the primary key, we require that you don't change it once you have saved your object the first time.
/Jonas Hogstrom [CapableObjects]
|
|
|
|
|
nagir
|
Posted 2009-03-30 06:50:54
|
|
Group: Forum Members
Last Active: 2010-08-11 17:02:44
Posts: 338,
Visits: 890
|
|
|
|
|
|
mtiede
|
Posted 2009-03-30 17:51:30
|
|
Group: Forum Members
Last Active: 2011-06-28 16:42:26
Posts: 487,
Visits: 1 277
|
Why would you ever want to change the primary key?
I suspect what you really want to have is a primary key (to use for relations) and ANOTHER attribute that is some sort of changeable attribute like ID for some sort of identification purpose like SSN or some such.
Maybe you are working with an existing database?
/mtiede
Environment:
Windows 7 Ultimate 64 bit
Delphi 6
Rad Studio 2010 Enterprise with Prism 2011
2009-03-30 17:52:43 by
mtiede
|
|
|
|
|
nagir
|
Posted 2009-04-02 02:22:14
|
|
Group: Forum Members
Last Active: 2010-08-11 17:02:44
Posts: 338,
Visits: 890
|
Why would you ever want to change the primary key?
...
Maybe you are working with an existing database?
Just system integration. So there's high possibility that lookup IDs will be different.
But I can change it using SQL and at this stage I hope I will not need to modify it at runtime.
So that's fine for now.
Cheers.
My Blog: http://dnagir.blogspot.com
|
|
|
|
|
mtiede
|
Posted 2009-04-02 18:38:09
|
|
Group: Forum Members
Last Active: 2011-06-28 16:42:26
Posts: 487,
Visits: 1 277
|
hmpff. With Sql Server at least, I didn't think you COULD change primary keys with Sql.
I don't quite understand your answer. Could you elaborate? Just curious...
/mtiede
Environment:
Windows 7 Ultimate 64 bit
Delphi 6
Rad Studio 2010 Enterprise with Prism 2011
|
|
|
|
|
nagir
|
Posted 2009-04-03 01:43:38
|
|
Group: Forum Members
Last Active: 2010-08-11 17:02:44
Posts: 338,
Visits: 890
|
With Sql Server at least, I didn't think you COULD change primary keys with Sql.
You can (if it is not identity).
Here's the sample (just run it from Query Analyzer or Management Studio):
if not exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[TestTable]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
begin
create table TestTable (
[Id] int not null primary key clustered,
OrderIndex int not null default(0),
Description nvarchar(255)
)
end
go
insert into TestTable (Id, OrderIndex, Description) values (1, 1, 'Australia')
insert into TestTable (Id, OrderIndex, Description) values (2, 2, 'UK')
go
update TestTable
set Id=3
where Id=1
select * from TestTable
go
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[TestTable]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
begin
drop table TestTable
end
go
I don't quite understand your answer. Could you elaborate? Just curious...
There's a system we develop on top of existing application (and database). During development we add some lookups.
But in production their values can easily be different as well as in in another instance of deployed application. That is legacy DB. But the main part is that we have another ECO Database and we have to push data from it to the legacy DB. So we need to make sure these 2 instances will work correctly and have the same lookup IDs.
(as a result in the example above front-ends that use the legacy database can always rely that TestTable.Id=1 is always Australia for one deployed system and TestTable.Id=3 is always Australia for another).
Huh. Hope I explained it better this time 
My Blog: http://dnagir.blogspot.com
|
|
|
|
|
mtiede
|
Posted 2009-04-03 14:42:53
|
|
Group: Forum Members
Last Active: 2011-06-28 16:42:26
Posts: 487,
Visits: 1 277
|
nagir (2009-04-03)
With Sql Server at least, I didn't think you COULD change primary keys with Sql.
You can (if it is not identity).
...
Ah. I have always used identities.
I don't quite understand your answer. Could you elaborate? Just curious...
There's a system we develop on top of existing application (and database). During development we add some lookups.
But in production their values can easily be different as well as in in another instance of deployed application. That is legacy DB. But the main part is that we have another ECO Database and we have to push data from it to the legacy DB. So we need to make sure these 2 instances will work correctly and have the same lookup IDs.
(as a result in the example above front-ends that use the legacy database can always rely that TestTable.Id=1 is always Australia for one deployed system and TestTable.Id=3 is always Australia for another).
Huh. Hope I explained it better this time
Yep, I see your problem. Haven't had to do such a thing. Maybe you could make the name be the primary key?
... time passes ...
On second thought, I did have one sort of like that once. What I did when the data came back to the "legacy" database, I looked up the name, Australia, and if it was found, I changed all the other incoming records references to be that value. If it wasn't found, I inserted the new record, got the ID of it, and updated all the references to that to be the new key. So I never updated the primary keys.
/mtiede
Environment:
Windows 7 Ultimate 64 bit
Delphi 6
Rad Studio 2010 Enterprise with Prism 2011
2009-04-03 16:16:00 by
mtiede
|
|
|
|