M
Mike
Does anyone know the range limit for the UID field? Is there a max value?
Thanks!
Thanks!
J
Jan De Messemaeker
I once read about 1 000 000 tasks being the limit, so UID must be capable of
that.
HTH
that.
HTH
J
Jim Aksel
It is a long integer ... 2,147,483,647 or 2^31-1 for a 32 bit processor
D
davegb
Jim said:
Good thing I'm not currently planning anything bigger than that!
J
Jack Dahlgren
Jim,
Are you sure about that? It is unsigned (positive only) so it would seem
that it is 2^32-1 or 4294967295 and indeed that corresponds to the "magic
number" that project increments UID's by when projects are consolidated.
-Jack Dahlgren
http://zo-d.com/blog
Are you sure about that? It is unsigned (positive only) so it would seem
that it is 2^32-1 or 4294967295 and indeed that corresponds to the "magic
number" that project increments UID's by when projects are consolidated.
-Jack Dahlgren
http://zo-d.com/blog
S
St Dilbert
Is that "full long int range available for unique id" documented
anywhere?
I do find the data type "long integer" when saving a project file as
access database and look at the data type. And of course a long int
stores in 4 bytes giving 2^32 combinations.
But in documents that come with project (I checked the help and
PJDB.HTM) I can only see all the unique id's described as "integer"
(defined as whole number of course but e.g. in Access meaning just 16
bit or 65535 max for unsigned). In fact there is not a single occurence
of "long" in PJDB.HTM according to the search function. I guess it's
just not detailed enough and why should project save as longint in
access if it's just standard integer.
Still the number could in fact be a lot lower than 2^32 imposed by
limitations in project internal functions like sorting/grouping, where
numbers get shuffled between several longint places and need to expand
quite a bit to run the function.
Frankly I can live with even a paltry 1 million tasks comfortably, but
I'm a bit nervous that one day a long-lived and
oft-consolidated-separated file will test the 65536 (2^16) limit...
So does anybody have better Microsoft sources for the unique id range
than me? Could you point me towards them?
anywhere?
I do find the data type "long integer" when saving a project file as
access database and look at the data type. And of course a long int
stores in 4 bytes giving 2^32 combinations.
But in documents that come with project (I checked the help and
PJDB.HTM) I can only see all the unique id's described as "integer"
(defined as whole number of course but e.g. in Access meaning just 16
bit or 65535 max for unsigned). In fact there is not a single occurence
of "long" in PJDB.HTM according to the search function. I guess it's
just not detailed enough and why should project save as longint in
access if it's just standard integer.
Still the number could in fact be a lot lower than 2^32 imposed by
limitations in project internal functions like sorting/grouping, where
numbers get shuffled between several longint places and need to expand
quite a bit to run the function.
Frankly I can live with even a paltry 1 million tasks comfortably, but
I'm a bit nervous that one day a long-lived and
oft-consolidated-separated file will test the 65536 (2^16) limit...
So does anybody have better Microsoft sources for the unique id range
than me? Could you point me towards them?
J
JD
St Dilbert,
The access definition of "integer" is plainly not applicable in this case.
The published specs for project (available in the help documentation show
that project is capable of holding "1 million" tasks. When project 2000 came
out I created test schedules with 10 inserted projects containing 10K tasks
each to test performance. That clearly exceeds the numerical limit that you
are worried about.
What I'm trying to get to is to tell you, "don't worry about it". I've never
seen anyone ever mention coming across this as a limitation and I've seen
some pretty large schedules maintained over a long period of time.
-Jack Dahlgren
http://zo-d.com/blog
The access definition of "integer" is plainly not applicable in this case.
The published specs for project (available in the help documentation show
that project is capable of holding "1 million" tasks. When project 2000 came
out I created test schedules with 10 inserted projects containing 10K tasks
each to test performance. That clearly exceeds the numerical limit that you
are worried about.
What I'm trying to get to is to tell you, "don't worry about it". I've never
seen anyone ever mention coming across this as a limitation and I've seen
some pretty large schedules maintained over a long period of time.
-Jack Dahlgren
http://zo-d.com/blog
S
St Dilbert
Hi JD,
thanks for pointing me towards the chapter "project specification" in
the help.
All the max values for project are listed in there nicely. So in fact
you can use only 0,02% (1 million divided by 2^32) of the longintrange
;-)....
Looks like all the values really have way enough range for my purposes.
Now if I could only figure out why I never looked for "specifications"
in help when I was searching for an answer to this - it's so OBVIOUS!
Looking at a small extract from the specifications page... hmmm..... so
i can only assign up to 60 million people to work an any one task... I
need to check that outsourcing deal again ;-)....
Tasks per project file 1 million
Resources per project 1 million
Resource units per assignment 60,000,000 units or 6,000,000,000%
Resource availability dates 100
Task dependencies per project file no limit
Predecessors per task no limit
Successors per task no limit
Outline levels per project 65,535
Consolidated projects 998
[and so on....]<<
thanks for pointing me towards the chapter "project specification" in
the help.
All the max values for project are listed in there nicely. So in fact
you can use only 0,02% (1 million divided by 2^32) of the longintrange
;-)....
Looks like all the values really have way enough range for my purposes.
Now if I could only figure out why I never looked for "specifications"
in help when I was searching for an answer to this - it's so OBVIOUS!
Looking at a small extract from the specifications page... hmmm..... so
i can only assign up to 60 million people to work an any one task... I
need to check that outsourcing deal again ;-)....
Tasks per project file 1 million
Resources per project 1 million
Resource units per assignment 60,000,000 units or 6,000,000,000%
Resource availability dates 100
Task dependencies per project file no limit
Predecessors per task no limit
Successors per task no limit
Outline levels per project 65,535
Consolidated projects 998
[and so on....]<<
J
Jim Aksel
I sit corrected, oh great one. I got that info from another site ... my
assumption was Long, not Unsigned.
Either way, we have a lot of tasks we can enter before worrying about it.
assumption was Long, not Unsigned.
Either way, we have a lot of tasks we can enter before worrying about it.
J
JackD
My latest post on my blog - from today - shows that the limit is in
processing power rather than limits to the tool.
http://zo-d.com/blog/archives/microsoft-project/microsoft-project-performance-limitations.html
Though if the tool was written more efficiently then the processing becomes
less of a bottleneck. In any case, I'm not certain how I'd deal with a
million tasks in a single schedule. To me that seems out of control.
-Jack
processing power rather than limits to the tool.
http://zo-d.com/blog/archives/microsoft-project/microsoft-project-performance-limitations.html
Though if the tool was written more efficiently then the processing becomes
less of a bottleneck. In any case, I'm not certain how I'd deal with a
million tasks in a single schedule. To me that seems out of control.
-Jack
J
JackD
Yep, only 60 million resources so be careful about it!
I did some testing today. You can find the results here:
http://zo-d.com/blog/archives/microsoft-project/microsoft-project-performance-limitations.html
On my machine at least, calculation time is the limiting factor.
-Jack
I did some testing today. You can find the results here:
http://zo-d.com/blog/archives/microsoft-project/microsoft-project-performance-limitations.html
On my machine at least, calculation time is the limiting factor.
-Jack
St Dilbert said:
S
St Dilbert
Amazing blog entry! This is serious research!
Just one side note: I don't think I'd be worried to break the task
number limit even if it just were 2^16 for just adding tasks. But since
it is a unique id that keeps incrementing after deletions etc. you can
end up with project files that have several hundred tasks stored only,
but the uid is already well into the thousands.
Anyway: with the theoretical limit of 1 million "active" tasks and the
numerical limit unsigned longint I can certainly go back to worry about
other project features for the next couple of centuries....
Just one side note: I don't think I'd be worried to break the task
number limit even if it just were 2^16 for just adding tasks. But since
it is a unique id that keeps incrementing after deletions etc. you can
end up with project files that have several hundred tasks stored only,
but the uid is already well into the thousands.
Anyway: with the theoretical limit of 1 million "active" tasks and the
numerical limit unsigned longint I can certainly go back to worry about
other project features for the next couple of centuries
....
J
JD
Ah, you do NOT have a couple of centuries. There is a limitation! Project
breaks at midnight Friday, December 31, 2049 due to the way dates are
stored.
I'm sure they will fix it by then...
-Jack
breaks at midnight Friday, December 31, 2049 due to the way dates are
stored.
I'm sure they will fix it by then...
-Jack
St Dilbert said:Amazing blog entry! This is serious research!
Just one side note: I don't think I'd be worried to break the task
number limit even if it just were 2^16 for just adding tasks. But since
it is a unique id that keeps incrementing after deletions etc. you can
end up with project files that have several hundred tasks stored only,
but the uid is already well into the thousands.
Anyway: with the theoretical limit of 1 million "active" tasks and the
numerical limit unsigned longint I can certainly go back to worry about
other project features for the next couple of centuries
D
davegb
JD said:
O no! The Y2K+49 crisis is just around the corner!
St Dilbert said:Amazing blog entry! This is serious research!
Just one side note: I don't think I'd be worried to break the task
number limit even if it just were 2^16 for just adding tasks. But since
it is a unique id that keeps incrementing after deletions etc. you can
end up with project files that have several hundred tasks stored only,
but the uid is already well into the thousands.
Anyway: with the theoretical limit of 1 million "active" tasks and the
numerical limit unsigned longint I can certainly go back to worry about
other project features for the next couple of centuries