Interesting problem. No technical answers here, but a question to help clarify...
By secure, do you mean confidentiality of the data or stability of the information? If it is confidentiality, then the security is tossed as soon as you extract the data into the view, regardless of where it came from. Stability can be addressed on 2 fronts: a) Address the perception that simply querying the data can impact stability. Correct me if I am wrong, but this seems to be more a factor of the efficiency of the querying tool than the SQL data itself. b) Develop a middle-ware solution. If confidentiality is an issue, then that will need to be considered. I developed a solution where information from .dbf files were extracted on a regular basis in XML format based on last update and inserted into a seperate SQL DB every 15 minutes or so, as even looking at dbf files can stuff them up due to date formats and record locking protocols. I could then query my SQL to my heart's content. Be interested in hearing what you come up with. Chad On 7/6/06, grant <[EMAIL PROTECTED]> wrote: > > ok thanks guys - i resent the impilication it's a dailywtf though scott! > > anyway, you've basically clarified the issue for me. I am now armed to > go back to my boss and say, we can do it this way... > > as for passing in parameters, yes you can query against a view with > parameters (as per dale's example above), but you can't actually call > a view like you do with a stored proc where you actually *pass* the > parameters to the proc. that's all i meant. > > it may seem a little stupid (why not just use stored procs) but it all > comes down to linked views - you can't link stored procs from one > server to another, but you can with views. we have a view on the > secure server that gets all data relevant to my site, and that view is > linked to a view on a non secure server that cf has access to. the cf > query pares back the initial dataset with parameters, but what i am > after is an abstracted way to query the secure db with those > parameters initally. did that make sense? > > it looks a little like this: > > secure sql server view (which is linked to the non-secure server): > SELECT * > FROM db1.tblclients > > ...which returns a huge resultset. > > non-secure sql server view: > SELECT * > FROM db1.the_secure_view_above > > and the coldfusion query: > SELECT * > FROM db2.the_non_secure_view_above > WHERE clientid = '666' > > and ultimately what i'd like to be doing in CF is: > SELECT * > FROM db1.the_secure_view_above > WHERE clientid = '666' > > but unfortunately the ppl in control here don't want me accessing > db1(secure) directly. which let me to the initial question. and this > following clarifaction. > > anyway, whatever, we'll get it sorted. i'm off to get my dose of > thedailywtf.......... > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie -~----------~----~----~----~------~----~------~--~---
