programming problem - ASP & SQL-Server

[citizen-k]

I am sending files which are stored inside my SQL-Server through an ASP page (response.binarywrite...)
I want to delete the file (the record in the table) after the user finished to download the file.
I DO NOT want to delete the file in case the download was not completed.

I need a server side solution. (no javascript asking the server to delete the file from the client side)

[Trident-za]

Why do you need a "server-side solution"? You could accomplish this very easily with a few lines of code.... and technically, I guess, the implementation of that code would be "server side" :)

PM me if you like, this is what I do for a living, although I usually use VBScript not JavaScript.

P.S. When you say you are storing the "file" in SQL Server, I assume you mean you're storing a link to it rather than the file itself?

[citizen-k]

Why do you need a "server-side solution"? You could accomplish this very easily with a few lines of code.... and technically, I guess, the implementation of that code would be "server side" :)

PM me if you like, this is what I do for a living, although I usually use VBScript not JavaScript.

P.S. When you say you are storing the "file" in SQL Server, I assume you mean you're storing a link to it rather than the file itself?

No, I store the file inside the DB. (as "image" type)

I'm using VB as well, so VB is fine :)

[Trident-za]

OK, first off - why the insistence on server-side? Whats wrong with using client side VBScript to delete the record?

Second, I need to know a bit about your database structure, table names, relationships etc. as well as what it is exactly you are trying to do.

Third, its almost midnight in South Africa, so you'll probably have to wait till tomorrow for anythign useful from me :)

[Herrmannek]

Why you want to delete file after uploading it to client?

[citizen-k]

OK, first off - why the insistence on server-side? Whats wrong with using client side VBScript to delete the record?

Second, I need to know a bit about your database structure, table names, relationships etc. as well as what it is exactly you are trying to do.

Third, its almost midnight in South Africa, so you'll probably have to wait till tomorrow for anythign useful from me :)

Its 1 after midnoght here so I'm on my way to bed as well...

Thing is: I have a table with the file's data (size, name etc'..) and a field which is 'image' type - thats where I store the file itself. (any file - not only images)

when a user asks for file "123" (file_id in the table) I select the image field (called file_iBinaryData) and then response.binarywrite it, after I'm sending the header:
<%
Response.AddHeader "content-disposition", "inline; filename=" & rs("cFileName")

Response.AddHeader "content-length", rs("iBinaryData").ActualSize
Response.ContentType = rs("cContentType")
Response.BinaryWrite rs("iBinaryData")
%>

the user can now save the file.

The reason I don't want the "delete" to come from the client side is because I don't want users to download a file more then once - coming from the client side it will be easy to 'hack' and then download the file more then once. deleting the record using (I'm making this event up) On_File_Download_Completed event on the server will help to pervent such 'hacks'

Thanks fot the help :hug:

(I'm trying to make a living from it too, but my neighbours aren't much of a help rofl )

[citizen-k]

Why you want to delete file after uploading it to client?

I want to delete it from the server. (to save space and because I dpn't want users to download files more then once)

[Jack Mehoff]

If you had a C++ / C# app serving the download instead of IIS, it could track the download state and could tell the last packet been sent to the client, though even then there is a small change the download is not successful.

With IIS hiding the transfer progress from you, you might need to do some hack like writing a temp file, and creating a read/write/flush cache loop that sends 4K - 32K chunks each loop. I haven't done any ASP in a few years but I remember there was some way to disable page buffering or write partial responses.

[citizen-k]

If you had a C++ / C# app serving the download instead of IIS, it could track the download state and could tell the last packet been sent to the client, though even then there is a small change the download is not successful.

With IIS hiding the transfer progress from you, you might need to do some hack like writing a temp file, and creating a read/write/flush cache loop that sends 4K - 32K chunks each loop. I haven't done any ASP in a few years but I remember there was some way to disable page buffering or write partial responses.

Yeah...I started checking the last option you offered (response.buffer=true and response.flush)

But it looks like I'll have to use C# to write something of my own to track the file download after all.

[Jack Mehoff]

Is this ASP or ASP.NET? Many people these days call ASP.NET ASP and VB.NET VB. Anyway, I'm only aware of a few options with ASP...


Use something like Informentum's ActiveFile (http://www.infomentum.com/ActiveFile/ActiveFileIndex.html) orMicrosoft's BITS (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=AD9FB937-62F9-4B9F-993B-F754F968B8A6) if you can limit the target platform.

[Trident-za]

One thing I'm curious about.... how many users are going to be "using" your database? And, do you have a table linking users and files? If you just delete the file the first time it's downloaded.... how are others going to download it?

I have no idea of your database skills, so I apologize if the above "insults your skills". I'm just trying to get a feel for how you've put this together. Experience has taught me not to take database knowledge for granted - I've seen databases "built" by extremely expensive developers who were quite obviously clueless :) In short, no offense intended... I'd be interested in how you handling this, though.

I have limited experience with server-side functionality (never really needed it) so I'm not sure how you would do what you need.

[citizen-k]

Right now it's ASP because I made a small demo - but I will transfer it to ASP.NET soon. (for the demo all I needed was a small form... so ASP was ok by me since I had all the methods written in advance)

The file is ment to be downloaded once by the user (or 3 times by 3 different users for that matter)

Right now I'm storing the files inside the DB only because its easier for my demo - the final system will be used by many users which will upload/download many files 24/7.

Other then tracking the file sending process - what do you think is best? store the files inside the DB or on the disk itself? (in case it should be on the disk - how can I store many files, some with the same name)
I mean, how many files/folder are ok? (storing 10,000,000 files in a single folder doesn't sound like a good idea...)

And... in case I will store the files on the disk - whats the best way to "send" them, other then providing a direct link? (I don't want users to get a link directing them to the files...I'd rather them get a URL with a fileID or something...)

[Herrmannek]

Right now it's ASP because I made a small demo - but I will transfer it to ASP.NET soon. (for the demo all I needed was a small form... so ASP was ok by me since I had all the methods written in advance)

The file is ment to be downloaded once by the user (or 3 times by 3 different users for that matter)

Right now I'm storing the files inside the DB only because its easier for my demo - the final system will be used by many users which will upload/download many files 24/7.

Other then tracking the file sending process - what do you think is best? store the files inside the DB or on the disk itself? (in case it should be on the disk - how can I store many files, some with the same name)
I mean, how many files/folder are ok? (storing 10,000,000 files in a single folder doesn't sound like a good idea...)

And... in case I will store the files on the disk - whats the best way to "send" them, other then providing a direct link? (I don't want users to get a link directing them to the files...I'd rather them get a URL with a fileID or something...)
I don't think that amount of files in folder slows down anything, but if you want be sure , read yours file system spec...

[citizen-k]

Right now it's ASP because I made a small demo - but I will transfer it to ASP.NET soon. (for the demo all I needed was a small form... so ASP was ok by me since I had all the methods written in advance)

The file is ment to be downloaded once by the user (or 3 times by 3 different users for that matter)

Right now I'm storing the files inside the DB only because its easier for my demo - the final system will be used by many users which will upload/download many files 24/7.

Other then tracking the file sending process - what do you think is best? store the files inside the DB or on the disk itself? (in case it should be on the disk - how can I store many files, some with the same name)
I mean, how many files/folder are ok? (storing 10,000,000 files in a single folder doesn't sound like a good idea...)

And... in case I will store the files on the disk - whats the best way to "send" them, other then providing a direct link? (I don't want users to get a link directing them to the files...I'd rather them get a URL with a fileID or something...)
I don't think that amount of files in folder slows down anything, but if you want be sure , read yours file system spec...

It takes longer to locate a file, depends on who's searching...

create 10,000 random files (size 0k or 1k) and copy them into your system32 folder and restart... your next post will be in 2008 ;)

[Herrmannek]

It takes longer to locate a file, depends on who's searching...

create 10,000 random files (size 0k or 1k) and copy them into your system32 folder and restart... your next post will be in 2008 ;)
Jihad in progres :), but in linux...windows' fat is shiat :)

for((i="1";i<="100000";i++)); do { echo $i; echo "File $i" > $i; }; done;

[Herrmannek]

I don't see difference, going for 0ne Milion :)

[Herrmannek]

BTW more advanced filesystems uses efficient data structures so heirarchy of files shouldnt matter...

[citizen-k]

Hehe...

Right now I'm using Windows (Demo), Linux is always an option... Although I'm not convinced its a better solution.

If you have a PHP example of how to control file transfer through the web I'll be happy to look at it.

[Herrmannek]

Hehe...

Right now I'm using Windows (Demo), Linux is always an option... Although I'm not convinced its a better solution.

If you have a PHP example of how to control file transfer through the web I'll be happy to look at it.

I think i'll run out of disk space something around 250000 file... :cantbeli: ,
I'm not much into web solutions because of few huge failures , but I''m curious how to do that.. so I will search for answer..

[citizen-k]

Thanks.

It's just a little thing I'm trying to develop on my spare time. (so I'm not restricted to a certain OS or platform)

[Trident-za]

Realistically, how many files are going to need for this app, whatever it is? And, again... how are you going to deal with different users needing the same file (which presumably was deleted after the first successful download). I am not trying to piss you off by asking this question... if you could explain in more detail how you propose to deal with this (or even better, what it is exactly that this app is about) I might be able to come up with an alternative which doesn't revolve around deleting files.... a "database solution" rather than a "file solution" so to speak....

P.S. It might just be that I've been reading these posts too quick and have missed the appropriate point.

[Trident-za]

To sort of clarify... if its possible to store all your files in one place, but have references to the files stored in a proper database structure, retrieving the files will be quick, because of the "indexes" etc. that SQL builds..... Also, adding and deleting references to files is easier to "undo" and "redo" than deleting the file itself, if you see what I mean....

[citizen-k]

After a file is uploaded to the server (by someone...) it can be downloaded once, and once only by a user. (one file can be downloaded by 3 users - but only once by each of them) When a file is downloaded I know who downloads it, and after the last user is downloading it - then I delete it. (so basicly I need to know when a file was downloaded ok to mark every user, and in case all the users downloaded it - then to delete it)

A file can be only for one user and can be for 100... it's dynamic.

In any case, the issue is not "other users" because only users who should downlod it will have the right URL. (And users who will try to steal files WILL get error messages)

The only problem is to know whether a file request ended ok or not, so I will know if I can consider the current user as a user who downloaded the file - so won't be able to download it again. In case a download fails - the user should still have the option to download the file of course.

[Trident-za]

OK... fair enough. If you have the "right URL" vs "error message" thing sorted, then a database solution is irrelevant/unneccesary. But, from reading your replies... how good are you at relational databases? Again, don't mean to knock your skills (I don't know them) ... but remember that a bad database design cannot be fixed by the best ASP developer on the planet. You have mentioned very little about your design... which sort of worries me.

P.S. I'd be interested to know how you solve the d/l thing... not an issue I've come across before, but interesting....

[citizen-k]

This DB is VERY small, all I use is 3-4 tables, and only 2 are used in that specific process, so DB design is not a part of the problem.

After 6 years of DB design, dealing with huge DB's with many tables + views + stored procedures + user defined functions + triggers +..... I don't think I have any thing to improve in that 3 tables DB ;)

Since the IIS is getting the whole file before it even starts sending it to the user I don't think its a DB issue - only server (IIS) side, unless I will use any events from the client side. (which I rather not)