Complex View creation question

I need to create a cross-database view (same server) in a master database.
The databases I'm joining in the view are listed in a table in that master.
I'd like for the view to automatically include new databases whose names are
added to that table in the master. How would I go about doing this? I'm no
t
familiar with dynamic sql... TIA.Views aren't going to have dynamic SQL in them, and I wouldn't really
recommend a multi-line table user-defined function even though you could
probably accomplish what you want by using dynamic SQL in it.
I would recommend a hook in your application/middle-tier (optimally) or a
trigger on that master table (less optimal) that would ALTER the view to
include all the existing databases in your master table whenever the list of
databases changes. Just create the ALTER VIEW statement based on the list
from the master table. If done from the app, you have many ways to do this;
if from a trigger, you'd create the SQL string via a cursor or a funky
SELECT statement and then execute it via EXEC (dynamic SQL).
The things to consider in this scenario would be: what impact does changing
the view have on the live system? how frequently does this change? does
the user adding/deleting records in the master table have permissions to
alter the view?
Mike
"William Sullivan" <WilliamSullivan@.discussions.microsoft.com> wrote in
message news:AD0E4C8D-1983-4003-B8FE-09D0222548F4@.microsoft.com...
>I need to create a cross-database view (same server) in a master database.
> The databases I'm joining in the view are listed in a table in that
> master.
> I'd like for the view to automatically include new databases whose names
> are
> added to that table in the master. How would I go about doing this? I'm
> not
> familiar with dynamic sql... TIA.

compile SP after creation?

Hello
Is it possible to force SQL Server to compile stored procedures after
creation? I mean, when I execute something like:
CREATE PROC SP1 AS
select * from X
where table X does not exist, I want to get error or warning. Now the proc
is created and the error is thrown only when it is executed. We have more
then 1500 stored procedures in the database now scripted out into sql
scripts. We want to ensure that scripts (and all objects like SPs, UDFs,..)
are valid after developers updates but by simply running the script to creat
e
DB and all its content does not produce any warning/error. How can we
accomplish that?
Thanks
eXavierHi
i can think about adding IF OBJECT_ID('Table') IS NULL which means if the
NULL then object does not exist and your error will be thrown
"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs,
> UDFs,..)
> are valid after developers updates but by simply running the script to
> create
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier|||Hi,
I'm not sure if I understand what you mean. Do you mean to write some sql
script parser, extract all table names from all stored procedures and then
call your IF check? This is not acceptable for us. In fact we want the serve
r
to compile procedures to get eventual errors.. SP is compiled when executed
first but we cannot automatically execute them all as they have different
parameters..
Any other idea?
Thanks
eXavier
"Uri Dimant" wrote:

> Hi
> i can think about adding IF OBJECT_ID('Table') IS NULL which means if the
> NULL then object does not exist and your error will be thrown
>
>
> "eXavier" <eXavier@.community.nospam> wrote in message
> news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
>
>|||Specify WITH RECOMPILE in your stored procedure. The procedure will not be
cached and will recompile at runtime.
--
MG
"eXavier" wrote:

> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs, UDFs,..
)
> are valid after developers updates but by simply running the script to cre
ate
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier|||Hi,
WITH RECOMPILE does exactly what you wrote. But it does not help in creation
time - you can still create procedure referencing non-existant tables.
The error is thrown only when the proc is executed, coming back to our
problem. (Further, if the SP compiles we want it to be cached.)
"MGeles" wrote:
[vbcol=seagreen]
> Specify WITH RECOMPILE in your stored procedure. The procedure will not b
e
> cached and will recompile at runtime.
> --
> MG
>
> "eXavier" wrote:
>|||I'm afraid you cannot do that
"eXavier" <eXavier@.community.nospam> wrote in message
news:4BBE6A41-D987-4A5C-A953-1BD71A01A972@.microsoft.com...[vbcol=seagreen]
> Hi,
> I'm not sure if I understand what you mean. Do you mean to write some sql
> script parser, extract all table names from all stored procedures and then
> call your IF check? This is not acceptable for us. In fact we want the
> server
> to compile procedures to get eventual errors.. SP is compiled when
> executed
> first but we cannot automatically execute them all as they have different
> parameters..
> Any other idea?
> Thanks
> eXavier
> "Uri Dimant" wrote:
>|||"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation?
Wayyy back in the day (SQL 6.5 I believe) this was possible, since SQL
checked for the existence of objects before creating stored procedures.
Apparently this caused a bunch of headaches, especially with database object
scripts that weren't created in the proper order, so "deferred name
resolution" was introduced. Table names are not resolved until run-time
instead of at creation time. Your best bet might be to 1) Do what Uri
suggested and explicitly check for the existence of tables yourself before
running the CREATE SP statement, or 2) Do what MS suggests below and test
your code after creation. Uri's suggestion should not be all that
difficult. Maybe a single script that tests for the existence of *all*
tables that are supposed to be in the database. You could run this script
before you try to run any SP creation scripts, and abort the mission based
on the result.
Here's what MS has to say on deferred name resolution:
"Deferred Name Resolution. Deferred name resolution allows procedure
compilation without all table references being present. Deferred name
resolution works in much the same way as the object-oriented concept of late
binding. At compile time, the compiler attempts to resolve all table names
that the procedure references. But if a table does not yet exist, the
compiler defers this name resolution until execution time.
For developers who have used temporary tables within their stored procedures
or triggers, this subtle new feature is long overdue. Although this feature
is useful, it has a side effect that many developers might initially
miss-the compiler no longer reliably catches table-name typos. Yes, you now
must test your code. This statement might sound funny at first, but if you
are not aware of deferred name resolution, you might find yourself wondering
why the compiler missed this error."
(From
http://www.microsoft.com/technet/pr...loy/migrat.mspx)|||Hi eXavier,
xyz's suggestion is reasonable. Appreciate your understanding that this
requirement is individual and actually limited by the design of SQL Server.
It is impossible for us to change the native behavior. I noticed that you
just wanted to ensure that scripts are valid after developers updates but
by simply running the script to create DB and all its content does not
produce any warning/error. You may consider to find a way from management.
For example, setup a test database environment which is same as the
development database then script a file to execute all the SPs or UDFs
that you want to check. This may require a standard process that the
developer of a SP or a UDF should provide a SQL test statement which can be
directly copied into the script file for checking at runtime. If some
errors are thrown out, please check and correct both the test database and
the development database. It is important to keep the identical environment
between the test database and the development database.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============|||You can catch most issues by executing the proc with SET FMTONLY ON like the
example below (passing any needed parameters as NULL values). However, some
errors can only be found by actually executing the proc.
SET FMTONLY ON
GO
EXEC dbo.SP1
GO
SET FMTONLY OFF
GO
Hope this helps.
Dan Guzman
SQL Server MVP
"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs,
> UDFs,..)
> are valid after developers updates but by simply running the script to
> create
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier

compile SP after creation?

Hello
Is it possible to force SQL Server to compile stored procedures after
creation? I mean, when I execute something like:
CREATE PROC SP1 AS
select * from X
where table X does not exist, I want to get error or warning. Now the proc
is created and the error is thrown only when it is executed. We have more
then 1500 stored procedures in the database now scripted out into sql
scripts. We want to ensure that scripts (and all objects like SPs, UDFs,..)
are valid after developers updates but by simply running the script to create
DB and all its content does not produce any warning/error. How can we
accomplish that?
Thanks
eXavierHi
i can think about adding IF OBJECT_ID('Table') IS NULL which means if the
NULL then object does not exist and your error will be thrown
"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs,
> UDFs,..)
> are valid after developers updates but by simply running the script to
> create
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier|||Hi,
I'm not sure if I understand what you mean. Do you mean to write some sql
script parser, extract all table names from all stored procedures and then
call your IF check? This is not acceptable for us. In fact we want the server
to compile procedures to get eventual errors.. SP is compiled when executed
first but we cannot automatically execute them all as they have different
parameters..
Any other idea?
Thanks
eXavier
"Uri Dimant" wrote:
> Hi
> i can think about adding IF OBJECT_ID('Table') IS NULL which means if the
> NULL then object does not exist and your error will be thrown
>
>
> "eXavier" <eXavier@.community.nospam> wrote in message
> news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> > Hello
> > Is it possible to force SQL Server to compile stored procedures after
> > creation? I mean, when I execute something like:
> >
> > CREATE PROC SP1 AS
> > select * from X
> >
> > where table X does not exist, I want to get error or warning. Now the proc
> > is created and the error is thrown only when it is executed. We have more
> > then 1500 stored procedures in the database now scripted out into sql
> > scripts. We want to ensure that scripts (and all objects like SPs,
> > UDFs,..)
> > are valid after developers updates but by simply running the script to
> > create
> > DB and all its content does not produce any warning/error. How can we
> > accomplish that?
> >
> > Thanks
> > eXavier
>
>|||Specify WITH RECOMPILE in your stored procedure. The procedure will not be
cached and will recompile at runtime.
--
MG
"eXavier" wrote:
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs, UDFs,..)
> are valid after developers updates but by simply running the script to create
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier|||Hi,
WITH RECOMPILE does exactly what you wrote. But it does not help in creation
time - you can still create procedure referencing non-existant tables.
The error is thrown only when the proc is executed, coming back to our
problem. (Further, if the SP compiles we want it to be cached.)
"MGeles" wrote:
> Specify WITH RECOMPILE in your stored procedure. The procedure will not be
> cached and will recompile at runtime.
> --
> MG
>
> "eXavier" wrote:
> > Hello
> > Is it possible to force SQL Server to compile stored procedures after
> > creation? I mean, when I execute something like:
> >
> > CREATE PROC SP1 AS
> > select * from X
> >
> > where table X does not exist, I want to get error or warning. Now the proc
> > is created and the error is thrown only when it is executed. We have more
> > then 1500 stored procedures in the database now scripted out into sql
> > scripts. We want to ensure that scripts (and all objects like SPs, UDFs,..)
> > are valid after developers updates but by simply running the script to create
> > DB and all its content does not produce any warning/error. How can we
> > accomplish that?
> >
> > Thanks
> > eXavier|||I'm afraid you cannot do that
"eXavier" <eXavier@.community.nospam> wrote in message
news:4BBE6A41-D987-4A5C-A953-1BD71A01A972@.microsoft.com...
> Hi,
> I'm not sure if I understand what you mean. Do you mean to write some sql
> script parser, extract all table names from all stored procedures and then
> call your IF check? This is not acceptable for us. In fact we want the
> server
> to compile procedures to get eventual errors.. SP is compiled when
> executed
> first but we cannot automatically execute them all as they have different
> parameters..
> Any other idea?
> Thanks
> eXavier
> "Uri Dimant" wrote:
>> Hi
>> i can think about adding IF OBJECT_ID('Table') IS NULL which means if
>> the
>> NULL then object does not exist and your error will be thrown
>>
>>
>> "eXavier" <eXavier@.community.nospam> wrote in message
>> news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
>> > Hello
>> > Is it possible to force SQL Server to compile stored procedures after
>> > creation? I mean, when I execute something like:
>> >
>> > CREATE PROC SP1 AS
>> > select * from X
>> >
>> > where table X does not exist, I want to get error or warning. Now the
>> > proc
>> > is created and the error is thrown only when it is executed. We have
>> > more
>> > then 1500 stored procedures in the database now scripted out into sql
>> > scripts. We want to ensure that scripts (and all objects like SPs,
>> > UDFs,..)
>> > are valid after developers updates but by simply running the script to
>> > create
>> > DB and all its content does not produce any warning/error. How can we
>> > accomplish that?
>> >
>> > Thanks
>> > eXavier
>>|||"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation?
Wayyy back in the day (SQL 6.5 I believe) this was possible, since SQL
checked for the existence of objects before creating stored procedures.
Apparently this caused a bunch of headaches, especially with database object
scripts that weren't created in the proper order, so "deferred name
resolution" was introduced. Table names are not resolved until run-time
instead of at creation time. Your best bet might be to 1) Do what Uri
suggested and explicitly check for the existence of tables yourself before
running the CREATE SP statement, or 2) Do what MS suggests below and test
your code after creation. Uri's suggestion should not be all that
difficult. Maybe a single script that tests for the existence of *all*
tables that are supposed to be in the database. You could run this script
before you try to run any SP creation scripts, and abort the mission based
on the result.
Here's what MS has to say on deferred name resolution:
"Deferred Name Resolution. Deferred name resolution allows procedure
compilation without all table references being present. Deferred name
resolution works in much the same way as the object-oriented concept of late
binding. At compile time, the compiler attempts to resolve all table names
that the procedure references. But if a table does not yet exist, the
compiler defers this name resolution until execution time.
For developers who have used temporary tables within their stored procedures
or triggers, this subtle new feature is long overdue. Although this feature
is useful, it has a side effect that many developers might initially
miss-the compiler no longer reliably catches table-name typos. Yes, you now
must test your code. This statement might sound funny at first, but if you
are not aware of deferred name resolution, you might find yourself wondering
why the compiler missed this error."
(From
http://www.microsoft.com/technet/prodtechnol/sql/70/deploy/migrat.mspx)|||Hi eXavier,
xyz's suggestion is reasonable. Appreciate your understanding that this
requirement is individual and actually limited by the design of SQL Server.
It is impossible for us to change the native behavior. I noticed that you
just wanted to ensure that scripts are valid after developers updates but
by simply running the script to create DB and all its content does not
produce any warning/error. You may consider to find a way from management.
For example, setup a test database environment which is same as the
development database then script a file to execute all the SPs or UDFs
that you want to check. This may require a standard process that the
developer of a SP or a UDF should provide a SQL test statement which can be
directly copied into the script file for checking at runtime. If some
errors are thrown out, please check and correct both the test database and
the development database. It is important to keep the identical environment
between the test database and the development database.
If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.
Charles Wang
Microsoft Online Community Support
======================================================When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================|||You can catch most issues by executing the proc with SET FMTONLY ON like the
example below (passing any needed parameters as NULL values). However, some
errors can only be found by actually executing the proc.
SET FMTONLY ON
GO
EXEC dbo.SP1
GO
SET FMTONLY OFF
GO
--
Hope this helps.
Dan Guzman
SQL Server MVP
"eXavier" <eXavier@.community.nospam> wrote in message
news:7A7CC2D9-36E5-4895-98A1-6FB7FA0325EE@.microsoft.com...
> Hello
> Is it possible to force SQL Server to compile stored procedures after
> creation? I mean, when I execute something like:
> CREATE PROC SP1 AS
> select * from X
> where table X does not exist, I want to get error or warning. Now the proc
> is created and the error is thrown only when it is executed. We have more
> then 1500 stored procedures in the database now scripted out into sql
> scripts. We want to ensure that scripts (and all objects like SPs,
> UDFs,..)
> are valid after developers updates but by simply running the script to
> create
> DB and all its content does not produce any warning/error. How can we
> accomplish that?
> Thanks
> eXavier

Compatibility Mode 70 databases in SP2

Hi,
Does anybody know if the creation of maintenance plans for Compatibility
Mode 70 databases will be possible with SQL Server 2005 SP2?
According to what I've heard so far, there is no chance to do that in
SP0/1 installations of SQL Server 2005 (CM 70 databases won't show up in
the wizard). I consider this a severe shortcoming in the product, which
should be tackled by MS.
Any opinions/workarounds?Hi
I would not say that this would be deemed a major issue as it is simple to
write your own maintenance procedures, and there are examples if you search
the web.
It is also recommended that compatibility mode is mainly designed as a
transient part of an upgrade and should not normally be something to be
relied upon long term, unless there is no way you can upgrade change the
database. If the latter is the case then your buisiness may be at risk if you
are relying on such software.
John
"Axel Bender" wrote:
> Hi,
> Does anybody know if the creation of maintenance plans for Compatibility
> Mode 70 databases will be possible with SQL Server 2005 SP2?
> According to what I've heard so far, there is no chance to do that in
> SP0/1 installations of SQL Server 2005 (CM 70 databases won't show up in
> the wizard). I consider this a severe shortcoming in the product, which
> should be tackled by MS.
> Any opinions/workarounds?
>|||Thanks for the answer, John.
Although I generally agree with you in saying that a compatibility mode
should not be used on a long-term basis, I have to make some additional
points on that topic:
a) We have deployed a lot of CM 70 databases; changing the compatibility
mode for them would not break our application, but it would give the
users very slow response times in parts of the app (this is due to the
change MS made to the query optimizer when it comes to selecting
indexes). We know we have to make changes to the app, but frankly, we
simply cannot afford the time for this now.
b) Most of our customers are not able to write maintenance procedures
(nor are all of our supporters).
c) There is no common scheme that our users follow when it comes to
backing up and checking their databases.
d) S2k5 supports maintenance plans for CM 80 databases, why not for CM
70 ones?
I think, that supporting CM 70 databases would not be a big deal for MS;
for us it would be.
Kind regards,
Axel|||Hi Axel
I suggest that you ship some standard jobs and procedures that will do this
for them and avoid the maintenance plans.
I don't really have any idea how widespread this issue is how much it would
actually take to implement this additional feature, but I can only assume
that it is not as big an issue as you think or MS is not aware of the
magnitude. If you wish to formally request a response and make them aware of
this issue I would raise a support call.
John
"Axel Bender" wrote:
> Thanks for the answer, John.
> Although I generally agree with you in saying that a compatibility mode
> should not be used on a long-term basis, I have to make some additional
> points on that topic:
> a) We have deployed a lot of CM 70 databases; changing the compatibility
> mode for them would not break our application, but it would give the
> users very slow response times in parts of the app (this is due to the
> change MS made to the query optimizer when it comes to selecting
> indexes). We know we have to make changes to the app, but frankly, we
> simply cannot afford the time for this now.
> b) Most of our customers are not able to write maintenance procedures
> (nor are all of our supporters).
> c) There is no common scheme that our users follow when it comes to
> backing up and checking their databases.
> d) S2k5 supports maintenance plans for CM 80 databases, why not for CM
> 70 ones?
> I think, that supporting CM 70 databases would not be a big deal for MS;
> for us it would be.
> Kind regards,
> Axel
>

Compatibility Mode 70 databases in SP2

Hi,
Does anybody know if the creation of maintenance plans for Compatibility
Mode 70 databases will be possible with SQL Server 2005 SP2?
According to what I've heard so far, there is no chance to do that in
SP0/1 installations of SQL Server 2005 (CM 70 databases won't show up in
the wizard). I consider this a severe shortcoming in the product, which
should be tackled by MS.
Any opinions/workarounds?Hi
I would not say that this would be deemed a major issue as it is simple to
write your own maintenance procedures, and there are examples if you search
the web.
It is also recommended that compatibility mode is mainly designed as a
transient part of an upgrade and should not normally be something to be
relied upon long term, unless there is no way you can upgrade change the
database. If the latter is the case then your buisiness may be at risk if yo
u
are relying on such software.
John
"Axel Bender" wrote:

> Hi,
> Does anybody know if the creation of maintenance plans for Compatibility
> Mode 70 databases will be possible with SQL Server 2005 SP2?
> According to what I've heard so far, there is no chance to do that in
> SP0/1 installations of SQL Server 2005 (CM 70 databases won't show up in
> the wizard). I consider this a severe shortcoming in the product, which
> should be tackled by MS.
> Any opinions/workarounds?
>|||Thanks for the answer, John.
Although I generally agree with you in saying that a compatibility mode
should not be used on a long-term basis, I have to make some additional
points on that topic:
a) We have deployed a lot of CM 70 databases; changing the compatibility
mode for them would not break our application, but it would give the
users very slow response times in parts of the app (this is due to the
change MS made to the query optimizer when it comes to selecting
indexes). We know we have to make changes to the app, but frankly, we
simply cannot afford the time for this now.
b) Most of our customers are not able to write maintenance procedures
(nor are all of our supporters).
c) There is no common scheme that our users follow when it comes to
backing up and checking their databases.
d) S2k5 supports maintenance plans for CM 80 databases, why not for CM
70 ones?
I think, that supporting CM 70 databases would not be a big deal for MS;
for us it would be.
Kind regards,
Axel|||Hi Axel
I suggest that you ship some standard jobs and procedures that will do this
for them and avoid the maintenance plans.
I don't really have any idea how widespread this issue is how much it would
actually take to implement this additional feature, but I can only assume
that it is not as big an issue as you think or MS is not aware of the
magnitude. If you wish to formally request a response and make them aware of
this issue I would raise a support call.
John
"Axel Bender" wrote:

> Thanks for the answer, John.
> Although I generally agree with you in saying that a compatibility mode
> should not be used on a long-term basis, I have to make some additional
> points on that topic:
> a) We have deployed a lot of CM 70 databases; changing the compatibility
> mode for them would not break our application, but it would give the
> users very slow response times in parts of the app (this is due to the
> change MS made to the query optimizer when it comes to selecting
> indexes). We know we have to make changes to the app, but frankly, we
> simply cannot afford the time for this now.
> b) Most of our customers are not able to write maintenance procedures
> (nor are all of our supporters).
> c) There is no common scheme that our users follow when it comes to
> backing up and checking their databases.
> d) S2k5 supports maintenance plans for CM 80 databases, why not for CM
> 70 ones?
> I think, that supporting CM 70 databases would not be a big deal for MS;
> for us it would be.
> Kind regards,
> Axel
>