I'll have to play with this. this is not a public website per say so multiple requests on this in a short period of time probably isn't going to be an issue. I'll have to look at this & decide how I want to do this. I'm assuming I either need to do away with this, or make both options selectable. this isn't a released product so if they didn't get the access to this feature it wouldn't be the end of the world. they are already getting a ton more features with this product then they would otherwise have, which is nothing.
Jeff "Philip Hallstrom" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > actually - I believe that may be a workable solution. you were mentioning > > checking the timestamp on a mysql table. how would I check the timestamp on > > a mysql table? > > see the timestamp data type. > > > even with this I'm betting it would be more time consuming to create the > > table then it would to pull the info from informix, and process validation 1 > > record at a time from mysql. that would be a simple query instead of an > > Yeah, but only the first time... if you get a lot of repeat traffic on the > same set of rows only the first "hit" will be slow since after that it > will all be in mysql... > > > insert. this would also all take place on the server it's self instead of > > pulling it from another server. I could load it up with ram & let it run. > > > > at any rate that gives me a lot of option to think about, and I'll probably > > has to work with some samples of the stuff from here to see what way is > > going to be the fastest. it would probably depend if the user was pulling > > this info in a session. if it was once, or several times. all something to > > think about. > > > > the other option I'm thinking about is just not giving the distributors > > access to this information, but restricting it to users with permissions to > > the entire batch only. > > > > thanks, > > > > Jeff > > > > "Philip Hallstrom" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Hmm... what about querying the informix database for the set of rows you > > > want all at once, putting that into a temporary mysql table with a > > > timestamp and then doing the rest of your work from there. > > > > > > Then the next time it happens check the timestamp on that mysql table and > > > if it's out of date, delete it and go and fetch updated rows from > > > informix, otherwise just use what's in that mysql table. > > > > > > This would act as a sort of replicated table, but only taking into account > > > the records that are actually being hit... > > > > > > maybe? > > > > > > On Fri, 3 Jan 2003, Jeff Bluemel wrote: > > > > > > > well - the informix database will be running on another server (a > > telecom > > > > billing system). this is a web based front end, and I really want to > > leave > > > > the other system alone 100%. if I were to modify anything I would make > > the > > > > mysql permissions table inside of informix, but there are liability > > reason > > > > which would keep me from doing so. > > > > > > > > still - you bring up an interesting point. a php script file that ran > > on > > > > crontab may not be a bad answer. however, again I would run into a > > problem > > > > of volume. there are an average of 3-4 million card in the informix > > server > > > > so I couldn't do this in a export & import. too may records, and info > > has > > > > to be accurate within 15 minutes. shear volume I believe is going to > > kill > > > > that idea. I would be back to 1 record at a time running every 15 > > minutes. > > > > I would think too much load, and more practical to do it 1 record at a > > time > > > > upon request which won't be too frequent. > > > > > > > > hoping there's another solution I'm not aware of, or over looked. > > > > > > > > Jeff > > > > > > > > "Philip Hallstrom" <[EMAIL PROTECTED]> wrote in message > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > Any chance you can do a somewhat frequent export from informix into > > mysql > > > > > or the other way around so all your stuff is in one database? > > > > > > > > > > -philip > > > > > > > > > > On Fri, 3 Jan 2003, Jeff Bluemel wrote: > > > > > > > > > > > ok - here's my problem. I have some data in mysql, and other data > > in > > > > > > informix. > > > > > > > > > > > > here is my application. this is for distributors of prepaid phone > > > > cards. > > > > > > prepaid phone cards have 3 numbers they can be identified by pin > > number > > > > > > (which is unique), or by batch & serial number. the batch number is > > > > > > basically the type of card, and the serial number & batch number for > > > > another > > > > > > unique identifier when used together. > > > > > > > > > > > > now - a batch can be given to several different distributors. > > > > therefore, > > > > > > when then are pulling various types of information on the batch they > > > > should > > > > > > only be able to see it for their cards, and not all of the cards in > > the > > > > > > batch. > > > > > > > > > > > > piece of cake right? well - the permissions information is kept in > > > > mysql, > > > > > > and the batch information its self is kept in an informix database. > > > > there > > > > > > is no way around this for me. > > > > > > > > > > > > the only way I can think of to work around this problem is to query > > 1 > > > > card > > > > > > at a time, and sum the info etc. together. however, there could be > > > > 400,000+ > > > > > > records, and this would be a slow tedious process. plus for each > > card > > > > I'd > > > > > > have to query the mysql database for permissions, and then in turn > > query > > > > the > > > > > > informix database in turn. this could take a long time to display > > the > > > > > > webpage. > > > > > > > > > > > > clear as mud??? recommendations? > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > PHP General Mailing List (http://www.php.net/) > > > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > PHP General Mailing List (http://www.php.net/) > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
