CREATE DATABASE ...

[Renzo....@gmail.com]

As a DBA I have a horrible experience of creating a test db from a
production copy. Out of 5000+ stored procedures there were 200 of
these with #temp table dependencies either this was created from the
applications or from the parent stored procedures. Rebuilding this
#temp table was painstaking because the developer did not leave any
trace how these tables was created. I have to look at each
applications source codes and some of them are already a legacy with
only the exe available.

I wish Sybase will have a new feature in creating a test
database copy from another db source were the only missing part is the
data.

Like:

create database testdb on dev1=### log on log1=## using proddb except
data

Somebody might say... well why not load a backup copy and then
truncate the tables. Well, this is possible if your prod db is less
than 300GB

Thanks..

[Jeff Tallman]

Did you try sybmigrate???

[Renzo....@gmail.com]

What I was concerned for is the stored procedure created this way:

create table #temp(userid_cd char(10),crdate datetime)
go
create proc getuserid
as
declare @uid char(10),@crdate datetime
select @uid=userid_cd,@crdate=crdate from #temp
...
go

I know sybmigrate relies on the UTIL DDLGEN and DDLGEN does not create
a temp tables for you. Does sybmigrate do it?

On Feb 14, 10:32 am, Jeff Tallman <jeff.tall...@sybase.com> wrote:
> Did you try sybmigrate???

[Cory Sane]

Renzo,

I've had the same problems... This is one of those cases where you have to
keep the build sql code stored safely way... I know that it is not always
possible when dealing with vendor applications.

Part of the trick would be to extract elements of the stored procs that we
cannot see. I also believe that this would be a good feature for users.

--
Cory Sane
[TeamSybase Intern]
Certified Sybase Associate DBA for ASE 15.0
not a Sybase Inc. employee
<Renzo....@gmail.com> wrote in message
news:c0cf3381-b2f4-4334...@p69g2000hsa.googlegroups.com...