Stupid request of the day
-
The easiest way to solve this is to insert a new row into a table and have G: as part of the content for a column's data. Now answer "yes" and if he asks for the data, just send him the row you just inserted. You are welcome. :cool:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
-
The easiest way to solve this is to insert a new row into a table and have G: as part of the content for a column's data. Now answer "yes" and if he asks for the data, just send him the row you just inserted. You are welcome. :cool:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
This guy knows what's up... :thumbsup::cool:
-
What I'm saying is this nonsense request could have an underlying question that wasn't stated, and could possibly be answered in a very simple and easy way... which would be a win for the one asking... and educational in a way that prevents stupid questions from coming up again, which anger and derail the developers.
-
Or worse, a clever programmer!
if (data.Contains("G:"))
{
// No one will ever use this value so we can use it for (some template?)...
}:~
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
From a colleague in our release team: >Do we have any field in the live database that contains "G:"? The database has approximately 600 tables, each having an average of about 25 columns, and the data stretches to about 3TB at the moment. WTF!
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
Time for the Wally Deflector... Dilbert Comic Strip on 2005-07-10 | Dilbert by Scott Adams[^]
-
From a colleague in our release team: >Do we have any field in the live database that contains "G:"? The database has approximately 600 tables, each having an average of about 25 columns, and the data stretches to about 3TB at the moment. WTF!
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
"So, you wanna know if we've a 'G' string riding up next to someone's colon, then?" :wtf:
Ask a stupid question...
-
Nope, sys.tables gives you the tables, sys.colums gives you the columns and sys.types gives the data types. You have to execute select statements on text type columns. You would have around 1000 select statements to loop through, not the actual data
You'd be looping all text-columns and memo-fields (up to 2Gb potentially), within all tables. That's two loops, continously crunching on the DB-server. To find a two-character string? The only correct answer can be that there'd better be a friggin' good reason for the request, and to request what the elephant they were doing so you can write a more specific query. I doubt that the two characters could hide 'anywhere'.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
You'd be looping all text-columns and memo-fields (up to 2Gb potentially), within all tables. That's two loops, continously crunching on the DB-server. To find a two-character string? The only correct answer can be that there'd better be a friggin' good reason for the request, and to request what the elephant they were doing so you can write a more specific query. I doubt that the two characters could hide 'anywhere'.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Hey, if his live depends on it, I'm suggesting a solution. Actually it's not that bad. you can: select TableName, columnName from whatever joins you need to do on all columns that are text, varchar, nchar etc. Then you run select count(ColumnName) from TableName where columName like '%whatever you search%' Let's say 1-2 secs per query on a table up to 1 million records, he will have the answers in a hour or two. It's a ridiculous request, but you know, if he absolutely needs to do it ...
-
Hey, if his live depends on it, I'm suggesting a solution. Actually it's not that bad. you can: select TableName, columnName from whatever joins you need to do on all columns that are text, varchar, nchar etc. Then you run select count(ColumnName) from TableName where columName like '%whatever you search%' Let's say 1-2 secs per query on a table up to 1 million records, he will have the answers in a hour or two. It's a ridiculous request, but you know, if he absolutely needs to do it ...
Bad Hombre wrote:
Actually it's not that bad.
Agreed, it is not 'that bad', but it is absolutely not what I want to hear from a specialist. Given the amount of data, and the type of request, and given that you have the freedom to make better suggestions, I'd expect one. Any decent database-operator will have a backup of anything on that server. Go search that and leave the production database alone. Ask where the customer "lost his G:", on which page, which application. Ask for a date-range. When did you have your G:? Ask whether it is actually feasible - in a database full with blobs you're bound to run into that combination, how do you know if it is the G: that the client is looking for, or just a random G:? Could it be in an encrypted or compacted field, and if so, do you want to search those too? Do you seriously need to search usernames and hash-columns, any logging-tables, if the customer cannot have lost his G: there?
Bad Hombre wrote:
It's a ridiculous request, but you know, if he absolutely needs to do it ...
Instead of doing something rediculous because you're simply told to do so, you could try and recognize a failure in communication and offer an intelligent alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Time for the Wally Deflector... Dilbert Comic Strip on 2005-07-10 | Dilbert by Scott Adams[^]
-
Bad Hombre wrote:
Actually it's not that bad.
Agreed, it is not 'that bad', but it is absolutely not what I want to hear from a specialist. Given the amount of data, and the type of request, and given that you have the freedom to make better suggestions, I'd expect one. Any decent database-operator will have a backup of anything on that server. Go search that and leave the production database alone. Ask where the customer "lost his G:", on which page, which application. Ask for a date-range. When did you have your G:? Ask whether it is actually feasible - in a database full with blobs you're bound to run into that combination, how do you know if it is the G: that the client is looking for, or just a random G:? Could it be in an encrypted or compacted field, and if so, do you want to search those too? Do you seriously need to search usernames and hash-columns, any logging-tables, if the customer cannot have lost his G: there?
Bad Hombre wrote:
It's a ridiculous request, but you know, if he absolutely needs to do it ...
Instead of doing something rediculous because you're simply told to do so, you could try and recognize a failure in communication and offer an intelligent alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters. Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution. :)
-
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters. Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution. :)
Bad Hombre wrote:
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters.
You might be choosing to actually exclude the columns that are actually required. Without asking, one is just guessing.
Bad Hombre wrote:
Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution.
Sometimes any solution is better than having nothing. There's no ranks here, so 'lowly' does not apply :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
The easiest way to solve this is to insert a new row into a table and have G: as part of the content for a column's data. Now answer "yes" and if he asks for the data, just send him the row you just inserted. You are welcome. :cool:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
Elegance is simplicity. The perfect solution.
I wanna be a eunuchs developer! Pass me a bread knife!
