April 9, 2003 at 2:03 pm
Here is my dilemma:
I have an idea for a retail application. Key to the application will be a database of about 500,000 records and performing various queries against the data. The user will not need to or be allowed to update the data. Currently I’m tweaking the records in Excel but I can export them anywhere.
My base of knowledge lies in Visual Basic and SQL Server. Because of this I would like to write the app in VB and use SQL Server as my backend. My question is: Is this feasible for a retail application?
There are 2 issues that concern me:
Licensing:
I know I can sell an app I wrote in VB without worrying about licenses. Is there a way I can use a SQL Server backend and also not worry about licenses? Or am I screwed here?
Installation:
Obviously I don’t want my users to need to install SQL Server just to use my application. I know with Access you can distribute a run-time engine with your setup files that will give the user just enough to “access” the Access database. Is the same true with SQL Server?
I have been scouring the net but have had difficulty finding answers to what seem like simple questions. Any help would be greatly appreciated.
Thanks,
Schroeder5
April 9, 2003 at 2:21 pm
Is you are worried about the lincense
then you should consider using MSDE. Wich is the engine (with some limitations)
of SQL Server. There are no problems in the license with this, is just the engine with
noc administering client tools.
If you don't espect to have a database above 2 Gb (This is a big limitation)
and don't plan to use replication(MSDE only allows the server to be a subscriber, not a publisher) then you should use
MSDE. I think you can download it from Microsoft's web page.
April 9, 2003 at 2:36 pm
Take a look at http://www.microsoft.com/sql/techinfo/deployment/70/msde.asp
Hope this helps get you started.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
April 10, 2003 at 3:49 am
However if you do decide to use MSDE I would suggest creating a version without MSDE that can be installed to a SQL Server of the users choice or even inside another MSDE instace. The biggest thing I hate are software packages that just install any MSDE instance behind the scenes. I just recently found myself chugging along on a machine that was normally fine and found three different apps had installed individual instances on the machine of MSDE. In addition to that the machine already had SQL Dev Edition running.
Here is good documentation of the product, including proper licensing and where to obtain http://www.microsoft.com/sql/techinfo/development/2000/msde2000.asp
April 10, 2003 at 12:27 pm
Thank you all for your replies - you've been very helpful.
I will look into MSDE as you suggested. I'm also still considering just using an Access database as I certainly don't want my small application to be a significant factor in the user's processer overhead.
Thanks again,
Schroeder5
April 10, 2003 at 2:01 pm
quote:
...I'm also still considering just using an Access database as I certainly don't want my small application to be a significant factor in the user's processer overhead....
Not sure about some of the newer versions of Access, but Access97/2000 has had performance problems with that amount of data...also be aware of maintenance issues. I've had numerous occasions where an .mdb file got corrupted easily on desktop apps with unscrupulous users...
just a heads up...
April 11, 2003 at 1:25 am
I would like too hook in on this thread as I also am developing a retail application with MSDE as data engine. My problem is deployment of stored procedures. I don't want customers to see definitions of stored procedures, create scripts, etc. When I do this with a command file calling SQL scripts, customers could read those SQL scripts. Are there any developers out there who could give any hints of how they deploy their apps?
Patrick
April 11, 2003 at 3:45 am
One way I have considered was using CAPICOM from MS (which is freejust search for in MSDN) and do like so.
Write a small app to Input the Stored Procedure in to save to a text file. However before saving to the file put the CAPICOM and encrypt to any of the formats supported thus the file is unreadable to them.
Then write another app to connect to the SQL server and database the updates are sent to, open the text file and decrypt, then run the SP script to make the changes.
Now just a little background here thou, even if you use the WITH ENCRYPTION method in the SP there are still ways to decrypt it so you may make it almost impossible to read the update as sent but if they really want they can get to it. So just make sure the effort is worth it.
April 11, 2003 at 6:48 am
Thanks Atares686 for your suggestion. I will try this.
About the encryption. I was thinking of not giving customers any account in the database so they cannot query the contents of the stored procedures anyway (encrypted or not). There will only be two accounts: one that is only known to the application (and which can only call stored procedures) and one that is only known to our support engineers (which can do administration tasks).
April 11, 2003 at 11:12 am
But the only problem there is you have to own the Server as well. As long as they have an account with Admin access on the Windows OS they can find a way in. Make sure you cover your bases fully.
Personally I would create a EULA with specific details on code modification, server modification and theft of code. I have seen these in other companies to the point we agree not to use any other means to hit the DB for even password resets without going thru the provided web interface.
April 11, 2003 at 11:51 am
Access .mdbs can be flaky. They are fine for non-critical uses, and if the users are trained to back up often and there are not a lot of users or the database size is small you should be ok.
If this is a critical app you should think long and hard before you develop with Access. Friends don't let friends do Access....
Seriously though, Access has problems with locking and security. There is no logging and once the .mdb is corrupt your best hope is a backup.
Patrick
Quand on parle du loup, on en voit la queue
April 13, 2003 at 10:57 am
Tp Pdolle... I would look into using the SQL DMO objects to connect to your SQL Server programmatically in Visual Basic and add and update your stored procedures there. Get around the script thing totally.
April 14, 2003 at 1:02 am
Contactanwar,
I was using your suggested approach until now (be it in C). However, in the new version of our software we will put more business logic into the database. Therefore, I am keen on using tools that enable me to develop this logic better and quicker (debug facilities, syntax coloring,etc.) and to apply changes easier.
It is a very daunting job having to do this directly in code. Of course, I could make some code generator that copies scripts into code automatically.
I am curious what approach other developers are taking.
Patrick
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply