How to hide sql code to client?

Hi,

Last couple of months ago I developed an web based application with asp.net(C#) 2.0 and SqlServer 2005. I am using visual studio 2005.

Few days ago my client complaint me that data are not saved in database correctly. I checked and found there is a logic bug in my application and I could fixed that bug. But I need to update the client's previous data in database.

I made a query like "Update tableName ....." and thus can fix the problem knowing client to execute this query to his database. But I don't like to show sql query/ code to client.

How could I fix this problem without showing the code to client?

Thank You

What do you mean by "showing the code to the client"? Do you not want the ASP.Net application displaying the code (it shouldn't be doing this anyway)? Do you not want your client (i.e. the boss) seeing the code?

If you need to run the SQL statements then you must have Remote Access to the clients SQL Server (I would guess that they do not give this out). Otherwise They must run it.

Actually I have an idea that I can simply made a form (C#.NET, desktop app.) with a installation file and ask client to install it and press the update button on the form. The update button will create an connection to DB and execute the query and thus update the DB. This I can hide the sql query to client.

I am asking you if there any better solution.

Thank You

I was going to recommend maybe creating an EXE for the client to run but you're going to have to do that every time a bug is found and data needs to be corrected. Your best bet is to talk to your client about maybe giving you remote access to the database or database server so you will be able to run your own scripts against the DB when needed.

Yeah you are right. But remote access is not possible here for several reasons. If there any other way.....

Your question is not really specific to ASP.NET, or .NET at all for that matter. This probably belongs in General Developer.

But anywho, you're pretty low on options at this point. Unless you can get remote access to the db (as Gary suggested), and run the update query yourself, you have no choice but to let the client do it.

It sucks you have to create a work-around for this, but it looks like that's all you can do at this point.

However, I want to ask a question. If there is a bug in the code that prevents the data from saving properly, why would they still be using the application?

Hi Blakk,

My client already using the updated version (after fixing the bugs) of the application. But I need to update there previous data in DB and I don't want to show the sql query to my client. I am searching for a solution.

Thank You for your question.

Could you add your sql code to an existing dll? If so then just update the dll and provide as an "update"

Thread moved.

Quote:

---

Originally Posted by nozu

My client already using the updated version (after fixing the bugs) of the application. But I need to update there previous data in DB and I don't want to show the sql query to my client. I am searching for a solution.

---

Why don't you want to show the SQL query to your client? The main reason they don't allow you to remotely connect and execute things against their database is to guard against running things they don't know about, so why try to circumvent it?

Quote:

---

Originally Posted by RobDog888

Could you add your sql code to an existing dll? If so then just update the dll and provide as an "update"

---

It sounded to me like he needed to update the data in which case this would only be run once. If this is true then bundling it into a DLL would be bad.

Does your client sit next to you or stand over your shoulder as you're working?

When you're fixing the bug, you have your head down, and are executing the query against the database. The only way the client could see it if you deliberately showed it to him.

I will say that we would not allow access to our Production database servers to anyone outside the company. In fact most people in the company do not have direct access to the databases.

Why do you want to hide the code from the client? Did they not know that the application had an error in saving data? Why hide the fix from them? Wouldn't their QA group want to know what was going on in the production envirorment?

Is the fix like an ALTER TABLE statement of just a query syntax fix?

I'm betting it will modify data in the databse.

Im betting its not a design update...

Quote:

---

I made a query like "Update tableName ....."

---

From post #1

Quote:

---

But I need to update the client's previous data in database

---

Kasracer is right. I need to run the query only once.

Neither I have remote access nor I can go to client end :). Client is far away from me. Only option is, I need to feedback my client through email with instructions.

Yup so its a meta data update or such and shouldnt have any security concerns or expose anything of value like operation sql action queries etc. Sholdnt really worry about letting them run it unless the OP feels they cant handle running a script.

I always inclued instructions for running the SQL if I'm not doing the work...

Changing Currency for a Customer
This is will need to be done in parts. There will be a table created in the Some database (CuurencyChangingSet). A stored procedure will be created in the Some database (proc_CurrencyChangeout). This procedure will take on input parameter, the number of records to process for a run (enter 1 to some max number). The third part of this process is an import of Excel spreadsheet data supplied by the customer. This is accomplished though the use of an SSIS package. The Excel spreadsheet needs to be in the specific format of two columns SlingID and CurrencyCode, the first row should not contain data but the names of the columns.

Installing to run:
1. Open SQL Server Management Studio connecting to the appropriate domeDatabase database (SomeDB for a 1 instance customer or SomeDB for an 2 instance customer).
2. Open a new query window.
3. Open the script CreateTableToHoldCustimerData.
4. Run the script (the script will transfer to the MeetingBroker database when it starts). This will create the table to hold the SlingIds and CurrencyCodes.
5. Open the script proc_CurrencyChangeout. This is the procedure that we will be running to perform the actual work.
6. Run the script (the script will transfer to the SomeDB database when it starts).
7. Copy the SSIS package (ExcelImport.dtsx) to a folder on the server. This server needs to have SQL Server Integration Services running on it (SSIS), in the Production environment.

Running the process
1. Import the supplied Excel spreadsheet (this needs to be done only once).
a. Open Windows Explorer and navigate to the folder holding the SSIS package ExcelImport.dtsx.
b. Double click on the package. This will open the package in the SSIS package execution application.
c. Select the Connection Managers in the left hand window.
d. Check the Excel entry and change then entry to the location that the Excel spreadsheet was saved to.
e. Check the SomeDB entry and change to the location for the appropriate SomeDB database (someInstacnce for a 1 instance customer or someInstacnce2 for an 2 instance customer).
f. Click on Execute.
2. Open SQL Server Management Studio connecting to the required database (someInstacnce for a 1 instance customer or someInstacnce2 for an 2 instance customer).
3. Open a new query window.
4. Change to the MeetingBroker database.
5. Run the check scripts to ensure that we are looking at Slings that belong to the required customer only.
a. The first query in the script can be used to gather the MeetingInfo records that will be changing and the current CurrenyCode for the record.
b. The second and third queries will generate the location name, City and Country that the Sling we are changing is assigned to (the someInstacnce Location)
c. The fourth and fifth queries will get channel information for the Slings that were imported. Query number four will only get data on Slings that do not have a someInstacnce Location and query number five will get the data for all Slings that were imported.
6. Execute the procedure proc_CurrencyChangeout as follows:
exec proc_CurrencyChangeout number of records to process

Damn Gary; might have been better to create an installation script... unless, of course, they have people with the ability to do this.

This is for use inside the company. The QA people and support personnel can all do this. I just supply basic instructions on what to do. I write all the scripts and SSIS package.