Skip to content

tsqlt.DropClass can't deal with some special characters in class names #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Prof-hu opened this issue Jul 15, 2016 · 5 comments
Open
Labels

Comments

@Prof-hu
Copy link

Prof-hu commented Jul 15, 2016

I had trouble with using DropClass while trying to figure out some standardized naming conventions for Class (test schema) names. The issue is there when there is a dot (ASCII 46) in the name.

Looking at the code of the procedure I noticed that when it is looking for the schema id, it uses SCHEMA_ID(@classname) everywhere, expect where it looks up the schema itself from sys.schemas. There it is using SCHEMA_ID(PARSENAME(@classname,1)). Not sure what's the goal with this, but once there's a dot in the Class name, PARSENAME will keep only the part after it, and SCHEMA_ID will not find the schema.

Prof-hu added a commit to Prof-hu/tSQLt that referenced this issue Jul 15, 2016
@tSQLt-robot
Copy link
Collaborator

Try wrapping the schema name in [brackets]. That should take care of your
problem.

Thanks,

Sebastian

On Fri, Jul 15, 2016 at 4:28 PM, Prof-hu notifications@github.com wrote:

I had trouble with using DropClass while trying to figure out some
standardized naming conventions for Class (test schema) names. The issue is
there when there is a dot (ASCII 46) in the name.

Looking at the code of the procedure I noticed that when it is looking for
the schema id, it uses SCHEMA_ID(@classname) everywhere, expect where it
looks up the schema itself from sys.schemas. There it is using
SCHEMA_ID(PARSENAME(@classname,1)). Not sure what's the goal with this, but
once there's a dot in the Class name, PARSENAME will keep only the part
after it, and SCHEMA_ID will not find the schema.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5, or mute the thread
https://github.com/notifications/unsubscribe-auth/ANR4Kku3UykmF1Ns82eIZGMkHoy69ccpks5qV-1ygaJpZM4JNwdx
.

@mbt1 mbt1 closed this as completed Jul 15, 2016
@Prof-hu
Copy link
Author

Prof-hu commented Jul 15, 2016

@tSQLt-robot

Try wrapping the schema name in [brackets]. That should take care of your problem. Thanks, Sebastian

Unfortunately that doesn't work either, I tried. That way SCHEMA_ID(PARSENAME(@classname,1)) works out, but SCHEMA_ID(@classname) doesn't. Therefore the procedure fails, as it will not find and drop the objects in the schema before trying to drop the schema itself. Unless the schema didn't have any objects in it, of course.

@mbt1
Copy link
Collaborator

mbt1 commented Jul 15, 2016

That is then a problem. I will look into it.

@mbt1 mbt1 reopened this Jul 15, 2016
@Prof-hu
Copy link
Author

Prof-hu commented Jul 15, 2016

@mbt1

That is then a problem. I will look into it.

Thanks!

Prof-hu added a commit to Prof-hu/tSQLt that referenced this issue Jul 15, 2016
@Prof-hu
Copy link
Author

Prof-hu commented Sep 8, 2016

Any update on this? Would be nice to have this fixed, so that I wouldn't need to apply workarounds in my projects.
We plan to integrate tsqlt into our CI process soon, a fix before that would make it even more straightforward.

@lizbaron lizbaron added the bug label Jan 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants