retrieve sql database stored procedures

if you go for detach/attach, it will SURELY bring all SPs as it is. there may be some user or login issue with you.

>>got the database working but the stored procedures did not come across to the new database with the same names as the source database.

Ouch.. using detach, attach?
That is something really weird.... what exactly do you mean.; if you check the SSMS, database, Procedures catalog, they do not appear?  Have you realigned permissions if you moved to a new server - it could be a permission issue?
Do you mean their names changed (never seen it)?

Better option is to export and import the database as it retains all the constraints and the procedures in place.

Hope this helps

Or maybe simpler, on source databse to export the sql creation statements for the sp's, then run these on the target database...

export and import not working because ssms not working on the source server.  added / changed logins and can acces the new database.  a stored procedure name in the source database for example see old sql 05 screen for stored procedures compared with the current 08 screen.  
stored-procedures-schldr-08.JPG
stored-procedures-schldr-05.JPG

All that looks like to me is that either
(1) you are comparing apples with oranges (not the same db); or
(2) an asp.net app has been installed against the database.  It introduces a whole lot of aspnet_* stored procedures.

Have you scrolled further down to see if your original procs are listed - they should be?

none of the old procs lised.  one more fact.  the old db had the name schldr1 as seen in the file mgr but schldr in ssms.  but when trying to attach to a newly created db named schldr got the error msg db already exists. so i set up a new db named tempdb then attached schldr1 to tempdb then imported the tempdb into the new schldr db.  i also wanted to get the db in the default location and the origingal attach left the db in the location of the soucrce file copied.  i think this cased the problem.  but how to do the attach so that the .mdf file ends up in the default sql directory and allows changing the name to schldr in ssms.

>  but when trying to attach to a newly created db named schldr got the error msg db already exists

Okay, so what you are saying is that you are comparing the "schldr" that ALREADY EXISTED against the "schldr" (file name schldr1) from the old server.  How do you expect them to be the same?

> so i set up a new db named tempdb then attached schldr1 to tempdb

You do know that "tempdb" is the system temporary workspace, so how exactly do you create a db named "tempdb" (exactly)?

Something is missing from this picture.

What you need to do is to forget what you did.  Delete/detach the current schldr db from the new server (if you really don't need it anymore), then move the files away (if detached).
Place the schldr1.mdf and .ldf files into the default sql directory.
Using SSMS, attach a db, find the schldr1.mdf file and name it as schldr (this works now that the other db is gone).
Finally, refresh the databases tree and you should see schldr with the procedures all intact.

yes i know this but as i stated previously.  the file name for schldr is schldr1 and the ssms name is schldr.  the db has two names when viewed in file mgr schldr1 when viewed in ssms schldr.  i do not know for sure how this coud be.  but we get an error msg db already exists when trying to attach, that canot be overcome directly in the ssms ui.  so somehow, we could change the name of schldr / schldr1(the source db)in order to attach as schldr or set up some kind of intermediary db then import or attach as (change name) schldr in the default sql data directory.  i don't remember exactly the temp db established previoulsy as an intrmediary but the process worked for geting the db across to an extent but not completely in that we did not get the user defined stored procedures.